智能体交接要带走的是判据，不是任务描述

队列里有一张卡已经超期两天，标题写着“止损位刷新失败被静默吞掉”。它前面还有四张卡，都是五天之内建的，说的是同一条链路的另外四个断面。

这五张卡不是五次事故，是同一件事被拆成了五份。

09-21 那张说，决策执行卡上的价位对自动监控结构性不可见，止损卡已经连续六个执行窗口落空。09-22 那张说，持仓表里两个字段的读数和交易历史互相矛盾。09-23 那张说，止损模型的输入从 08-26 起就断了，15 只持仓的止损位全部退化成一个用当前价算出来的数字。09-24 那张说，三处生产数据的静默失效全部是别的工作顺手撞见的，其中一处就在风控里。四张卡，四个接手的人，四条修复路径。

这四张卡摆在一起，重复的痕迹就藏不住了。

摆在一起看，第一反应是同一个问题被反复诊断。真正的问题是为什么： 摆在一起看，第一反应是同一个问题被反复诊断。值得往下问的是为什么：接手的人不笨，工具也都在，重复发生在信息从上一手传到下一手的那一步。我们的判断是，这类返工的根因不在接手的人，在交接的载荷。我们交接的是描述，不是判据。

一、协议已经定义好了任务，没定义“上次为什么关”

我们用的是 A2A。一次协作被定义成一个 Task 对象，带 taskId 和 contextId，产物是 Artifact，由 Part 组成，可以是文本、文件引用或结构化数据。状态机有明确的终态：completed、failed、canceled、rejected。跑得久的任务用推送通知回传，客户端可以随时取回状态、产物，必要时连历史一起取。

这套设计的价值在于让一条任务可以被对方追踪、取回、回放。你要注意的也是它停在哪里。协议没有规定“上一次这条任务为什么被关闭”要随任务一起移动。状态机是协议管的事，判据是载荷管的事。从协议里买到的是可追踪性，不是可判定性。

也就是说，协议能告诉你这条任务现在停在哪一步，不能告诉你它上一次为什么被停下来。

这句话听起来抽象，落到一张卡上很具体：接手的智能体或人能查到这条任务当前是什么状态，查不到它上一次为什么被关掉、当时凭的是什么证据。于是它只能重新诊断一遍。

结果是一样的：接收方只能把诊断重跑一遍。

这意味着你还要自己补一层：任务停下来的时候，把原因写进任务自己的字段里。

二、交接时最容易掉的三样东西

第一样是验证条件。它决定这件事在你手里算不算做完。掉了之后，完成标准退化成“看懂了就行”，而“看懂了”是接收方的自述，既不能复核也不能交接给第三个人。

所以“看懂了”这种标准传不下去，它只存在于当时那个人的脑子里。

第二样是上一手的结论。我们前面那四张卡里，每一张的接手人都重新查了一轮，他查到了什么、为什么决定关闭，这些结论如果不跟着任务走，下一手就只剩症状可以开始，而症状的清单永远比根因的清单长。

第三样是到期与归属。谁接的、什么时候到期、超期之后交给谁。我们自己的队列里，11 条超期任务全部带着可执行的检查命令。最早的一条压了七天，其中 6 条标了高优先级。我们自己的队列里 11 条超期任务中，11 条都带着可执行的检查命令，最早的一条压了七天，其中 6 条标了高优先级。它们说不清的不是怎么验收，是没有人被指定在某个时刻必须把它做完。

所以要落实的不是更认真地交接，而是把这三样变成字段。

这些都不是信任问题，接手的人手里确实没有一件可用的东西。

三样都掉出去之后，接收方只剩一件事可以做：重做一遍诊断。这不涉及信任问题，是没有任何可用的东西可以被信任。

这三样的失效还有顺序。先掉的是验证条件，因为它看上去最像多余的话；然后是上一手的结论，因为写下它的人已经在准备离场；最后是到期与归属，前两样没了之后，这条任务在系统里只剩一个标题，而标题没有人认领。我们手上的五张卡正停在第三步。

三、为什么任务描述必然丢判据

描述的完整性标准是读者读懂了，判据的完整性标准是检查能跑。这两个标准看着只差一点，实际差在能不能省略。一段描述少写一个边界条件，读起来仍然完整，作者自己都不会觉得缺了什么；一条判据少写一个条件，它立刻跑不出正确结论，任何人都会发现。

换句话说，两者的差别不在严不严格，在能不能省略。

这就是条件句总被删掉的原因，它们不改变读起来的完整感，却把判断条件带走了。

所以载荷一旦降级成散文，掉出去的恰恰是那些写了才显得啰嗦的条件：输入是不是新鲜的、这个值从哪来、失败时算不算通过。而这些正是判断这件事有没有做成的全部内容。散文写得越顺，丢得越干净，因为顺本身要求删掉条件句。

制度层面也能解决这件事，比如要求每次关闭任务都写一份复盘。这条路的效果取决于谁去检查，而检查的供给永远少于任务的供给。把同一件事写成字段，效果取决于数据库，数据库不会漏看。两者的差别不在严格程度，在检查的供应量。

这就是为什么一份写得很流畅的交接说明，下一手反而更容易漏掉条件。

这个机制你可以当场验一次：把一段交接说明里的条件句全部删掉，它读起来只会更顺。

如果这个机制成立，同一个根因会以新建任务的形式反复出现，而且每一条都从症状开头。我们刚过去的一周就是这条预测的读数：同一条链路上五张卡，卡面上偶尔提到前一张的编号，但没有一张把上一张的结论放进必填的位置。

四、我们自己的两个数字

我们把自己运行的任务队列当作样本看了一眼，读数是 2026-09-28 早上八点的快照：50 条在办任务里，32 条填了验收标准，31 条带一条可执行的检查命令。换成人话，约四成的任务在交接时，没有一个人能不看上下文就说出它算不算做完。

换句话说，四成的交接在开工之前就没有可判定的完成标准。

这两个数字的意义在方向，不在量级。

这两个数字来自我们自己的队列，不是外部调查，样本量也不值得当基准引用。它们有用的地方在于方向：字段的覆盖率是可以逐周往上推的，靠的不是要求团队更认真，是把它们设成必填。

五、我们的判断

交接的可判定性由载荷的字段决定，不由接收方的能力决定。把“读得懂”当作接收方的默认能力，等于把重建上下文的成本推给下一手，而且这笔成本不会出现在任何一张工时表上。

在人和人之间，缺字段的表现是返工，双方还能互相追问；在智能体之间没有追问这一环。接收方按字面执行，你少写的条件它不会替你补，它只会照着你写的跑完，然后返回一个看起来正常的结果。这也解释了我们为什么把多智能体系统的第一类资产放在载荷的 schema 上，而不是放在编排界面上。

拿我们自己的队列当样本有明显的局限，它是单一样本，做的又恰好是我们这一门生意，所以这些数字只能说明方向，不能说明普遍情况。方向这一层反而更可靠：字段覆盖率是可控的、逐周可以复算的，不需要等外部数据。

因此我们对编排层的排序很直接：先把载荷的字段定下来，再谈界面。

六、把交接载荷压成三个必填字段

你自己手上的任务在移交之前，至少应该带三样。第一样，验收命令：一条能跑的检查，返回通过或不通过。第二样，上一手快照：上一次为什么被关闭，当时的证据在哪，一条链接或一个可复算的指针。第三样，到期与归属：谁接、什么时候到期、超期交给谁。

这意味着交接质量不需要一套新的评分体系，只要把三个字段设成必填。

如果现在只能加一样，加第一样。没有验收命令的任务，无论执行得多漂亮，都无法被判定为完成，于是它只能靠人记得去做，而人的记忆不是状态机。

再配一个指标：重复建卡率，也就是三十天内因同一根因新建的任务数。它比任务总量诚实，因为任务总量数的是动作，重复建卡率数的是没被真正解决的部分。

写验收命令有两个常见的坑。第一个是把命令写成只能在作者机器上跑的东西：它引用了本地路径、一份还没提交的脚本、或者只有他知道的账号。下一个人跑不动，命令就退回成一句话。它引用了本地路径、一份还没提交的脚本、或者只有他知道的账号，于是下一个人跑不动，命令就退回成一句话。第二个是把命令写得太容易通过。我们自己的例子里，检查脚本检查的是进程在不在，而真正出问题的从来不是进程，是它算出来的那个数。一条只会通过的命令和没有命令的区别，在于前者会让你更放心。

七、快照里该写什么

快照不是给我们自己看的复盘文档，它只服务一件事：让下一手不必重查一遍。你可以把它当成留给下一个人的三行话，三行就够。

第一行是结论，一句话说清当时为什么关闭：修好了、判定为误报、或者转成了另一类工作。第二行是证据指针，要能被复算，可以是一条查询、一段日志的行号、一个哈希，而不是“见群里的截图”。第三行是当时排除掉的假设，这一行最省时间，因为下一手最先会走的那条路，通常就是你上一次已经走过并否掉的那条。

我们自己的队列里，这三行没有格式，也没有必填。所以卡面上偶尔会出现前一张卡的编号，但那仍然是叙述，不是字段。叙述会不会被读到，取决于下一个接手的人有多闲。

说白了，快照服务的是下一个人，不是写它的那个人。

这就是为什么我们把快照写成三行，而不是写成一篇复盘。

八、什么情况下不该用这套字段

因此边界要一次说清楚，不然这套规则会自己长大。

这套要求对我们是有成本的，所以有两条边界值得写清楚，否则它会变成一种只增不减的仪式。

因此边界适合一次性写进模板，而不是留在每次讨论里。

第一，一次性的排查不适用。坏了、看一眼、改掉、结束，这种任务加三个字段只会让流程更长，它本来就不会交到第三个人手上。第二，结论不可复算的探索任务不适用。让模型先跑二十个方向看哪个有信号的时候，硬要一条验收命令，只会逼人去写一条假的。这类任务需要的是另一套载荷：预算上限、停止条件、谁有权叫停。

反过来看，只要一件事会被第二个人接手、会被第二次打开，字段就是便宜的。判断标准不是任务大小，是它会不会回来。

九、采购多 agent 编排平台时的三个问题

一、任务交到下一个执行者手里时，载荷里哪些字段是必填的？要一份 schema，不要一张界面截图。必填项存在的证据是：缺了它，任务创建失败。

二、一次任务被关闭时，“为什么关”写在哪里，机器能不能读？如果答案是一段复盘文档，那么下一手取不到它，因为它不在任务的移动路径上。

三、超期与升级的判据是什么，触发之后谁被通知？这道问题问的是系统有没有能力在没有人类盯着的时候自己把问题交出去。

也就是说，这三道问题问的是同一件事：缺了它，系统会不会报错。

这也是买家最容易在现场问倒供应商的一题。

十、明天就能做的两件事

第一件，给现有的任务对象加两个字段，验收命令和上一手快照，把填充率当成交付指标看，每周往上推。第二件，挑一条你最依赖的链路，数一遍近三十天因同一根因新建的任务数，再数其中有多少条把上一手的结论写进了载荷。

同样地，这个数字每周重算一次就够，不需要实时看板。

重复建卡率算起来比看上去难，口径要写死，否则它会变成一个每年都能上修的漂亮数字。我们用四条：窗口三十天；按根因聚类而不是按标题，聚类由人做，每周一次；同一根因在同一窗口内重复出现才计入分子；被判成不同根因的，要在快照里写清为什么不同。这四条没有一条需要新系统，需要的是一周十分钟。

在我们自己看，后一个数字比任何成熟度评分都更接近真实。它不需要额外系统，只需要你愿意承认那些重复出现的任务本来是同一件事。

来源

Agent2Agent (A2A) Protocol Specification，v1.0.0，Task 对象、Artifact 与终态定义： a2a-protocol.org/latest/specification。

队列读数（50 条在办任务、32 条验收标准、31 条检查命令、11 条超期）来自我们自己运行的任务队列，2026-09-28 08:00 许快照，属一手运营数据，非外部调查，不可作为行业基准引用。