回答不等于负责

一次回答可以失败后重问，一次真实动作可能已经发信、建资源、扣款；副作用要有幂等键、收据和明确阶段，跨 Agent 交接用结构化移交包。

一次回答错了，你可以再问一次。一次真实动作错了，邮件已经发出去、资源已经建好、钱已经扣掉了。当模型可以写文件、跑命令、登录网站、部署服务、花钱和修改生产数据时，最重要的不再是推理质量，而是：以谁的身份行动、只能触达什么、中断后能否恢复、结果如何验证、副作用如何审计、"完成"由谁认定 agent-trend-2026。

三个阶段和一次对账

副作用型 Tool 的执行要分成三段：dispatch 前记录意图并生成幂等键；dispatch 后记录"已发出"；结果确认后写回结果并生成收据。分段的目的只有一个——让每一个时刻都能回答"这个动作现在处于什么状态"。

关键场景是进程在结果确认前崩溃。那些结果不确定的动作必须走 reconcile 对账：去问外部系统这次调用到底成没成，拿到确定的状态再决定下一步。禁止盲目重放——重放一次结果不确定的扣款，就是把一次故障升级成一次赔付。

配套两件事：幂等键要由业务语义生成（订单号加动作类型），而不是随机生成，否则重放时你认不出这是同一次意图；下游还要再兜一层业务防重，因为幂等键只在你的系统边界内有效。

移交包要有八个字段

结构化的 Handoff 需要八个字段：目标范围、已验证事实、未决假设、当前 checkpoint、待确认副作用、审批状态、停止条件、结果交还对象。只传一段自然语言摘要，是把上下文丢失伪装成组织分工 agent-trend-2026。

最常被漏掉的是第五个和第八个。待确认副作用决定接手方要不要先对账再动手；结果交还对象决定这件事到底算谁的——没有它，交接就成了"我把球扔出去了"，责任在传递中消失。

还有一条纪律：Handoff 里的陈述只能当线索，不能当事实。多个 Agent 互相读取对方的总结，很容易形成"彼此强化却缺证据"的结论——A 说它验证过 X，B 基于 X 继续推进，追溯时发现根本没人跑过那个测试。

消息语义要分级

协作消息分成四档，越往上权限越大：

• Comment 沉淀共享事实，不触发执行。
• Mention 是明确投递，告诉某个角色"这和你有关"。
• Handoff 携带成果与证据，转移责任。
• 结构化结果（完成、阻塞、失败）是唯一能改变任务状态的东西。

普通消息和单次模型调用的结束都不能改状态。一次模型调用可以中断恢复，它的结束不构成闭环——否则你会遇到"Agent 说了完成，任务却卡在同一处"的状态漂移。

Task 与 Job 双抽象

淘天塔罗平台把这件事拆成两层。Task 是持久化目标锚点，结构化记录最终结果、范围、明确不做的事、上游依赖、完成证据和当前阶段——Agent 第 5 分钟和第 50 分钟的上下文完全不同，但 Task 不变，它是"有没有做完"的系统判断依据。Job 是最小执行单元，必须明确解决什么问题、可以用哪些结构化结果结束、必须留下什么证据、不同结果流向哪里 taotian-loop。

Agent 声明完成不等于闭环。目标、证据、出口同时成立才算闭环。这样拆分的好处是失败被限制在当前 Job：Task 从受影响的阶段继续，不需要整体重启。

执行账本同样要分行：文件改动、命令、Mock、截图、Diff、测试结果是事实，进账本；方案理由和剩余风险是判断，走 Comment 和 Handoff。两类混在一个字段里，事后你就分不清哪些是可复查的证据、哪些只是当时的推测。

代价与自检

Bun 从 Zig 迁移到 Rust，百万行代码、6755 个 commit，合并之后仍然出现 19 个 regression。这不是 Agent 不行，而是它的能力边界：机械迁移可以被推到既有验收器覆盖的位置，测试没表达出来的行为仍然会逃逸 agent-trend-2026。结论很直接——验证成本比生成速度更值钱。

代价也清楚：幂等键、收据、对账和结构化移交包都是要写的代码，短链路任务会觉得啰嗦。判据是动作是否不可逆：能安全重试的调用，三阶段可以从简；会发信、建资源、扣款的动作，一个阶段都不能省。

三个问题自检：你能说出每个副作用型工具现在处于哪个阶段吗？进程在结果确认前被 kill，你有对账路径吗？把最近一次 Handoff 拿出来，里面有没有"待确认副作用"和"结果交还对象"？