一次修复结束后，Amp 可以把有用线索交给下一条代码任务

一个空值处理 Bug 修完，接下来想查“其他模块有没有同样写法”；一个只面向个人的功能做好，下一步要扩展到团队。后续工作依赖刚才的发现，却已经是另一个目标。Amp 的 Handoff，正是为这种连续任务准备的交接入口。

值得看的结果，不是一段把所有聊天压短的摘要，而是给下一项工作留下相关代码、决定和线索。新线程可以保持目标清楚，又能回到前一条线程查原始过程。

下一步做什么，决定带走什么

官方 Handoff 介绍用过三个很具体的场景：把个人功能扩展到团队，执行既有计划的第一阶段，以及检查代码库中其他需要相同修复的位置。它们共同的特点是后续任务不同，需要带走的材料也不同。

例如，修复结束后继续检查同类问题，真正需要的可能是触发条件、原来有问题的代码模式、修复方式和相关测试，而不是前面所有安装依赖的过程。按这个新目标提取上下文，后续代理就有一个更明确的调查起点。

这仍是上下文交接，不是把旧结论自动变成新位置的正确答案。同样的语法，在另一个调用场景中可能有不同业务约定。新任务需要重新阅读对应源码，再判断是否应该采用相同修复。

Amp 当前线程文档把 thread 定义为一项工作记录：包含提示、回答、工具调用与文件变化。线程有自己的 URL，可以在不同界面打开；代理实际运行在云环境、runner 还是本地 CLI，则是另一层设置。

当前也可以直接要求代理“Handoff and …”，说明下一目标。官方后续更新说明指出，代理会启动带相关上下文的新线程继续工作，不必再记旧版按钮或命令位置。

假如后续仍缺一段原始依据，可以在提示里引用旧线程的 URL 或 @T-…，让代理抽取与当前问题有关的内容。它提供的是有来源的补充路线，不必把长对话整体重新放回新任务。

线程的用途还延伸到代码审阅。当前文档说明，代理生成的提交带有 Amp-Thread-ID trailer，方便从 Git 历史追到产生改动的线程。把链接放入 PR 描述，也能让审阅者继续看过程，而不仅是一句“AI 修改了这些文件”。

线程还可以导出 Markdown，创建者可导出完整 JSON。需要整理交接材料时，这些是可保存的原始记录，但并不自动成为经过审核的开发文档。

分享前要选择可见范围：私人、工作区、组或持有链接的人，看到的范围不同；链接可访问也不代表对方有仓库或运行环境权限。账号、模型调用和云端环境则按 Amp 当前服务条件使用，不能从线程可导出推导成整套服务开源。

我会把 Handoff 用在“上一件事已经留下成果，下一件事依赖其中一部分”的转折处。保留能指导下一步的线索，再让每个线程交付各自的代码结果，长项目也更容易回看为什么这样改。