为什么 AI Agent 会在任务中途偏离，以及多 Agent 系统如何解决这个问题

https://video.wixstatic.com/video/a38d11_d47bff67c94f4e289473ef1a63002092/1080p/mp4/file.mp4

规格输入进去，一个可工作的应用输出出来，而每一步都可以在 Jira 中追踪

将专业 Agent 编排锚定在 Jira 上，让复杂编码任务始终贴合规格要求。

你可能已经有过这种感受：你把一项真实的工作交给一个能力不错的 AI Agent，给它一份完整的规格说明，其中包含边界情况和验收标准。刚开始的几分钟，它表现得很敏锐；但随后它开始滑坡，忘记了十分钟前自己做过的决定，重写原本已经正确的内容。到最后，你不得不和上下文窗口搏斗，不断重构提示词，重复指令，甚至偶尔加上一句“不要做 XYZ”，才能把 Agent 拉回正确轨道。

模型明明可以写出不错的代码。问题在于，它正在努力把整件事一次性都装进自己的记忆里，而这超出了它的承载能力，于是它开始失控。（这也在消耗你的时间和 token。）

为什么 Agent 会偏离规格？

Agent 是在一个工作记忆窗口里进行推理的。架构、产品意图、用户体验、它正在编写的测试，所有这些内容都挤在同一个空间里。小任务还放得下，但真正的功能开发往往放不下。随着上下文窗口被填满，Agent 会悄悄牺牲早期决策，为新信息腾出空间。那些明确写下来的指令，也会开始被忽略。你最先注意到的迹象，通常是它违反了一条你不得不再次强调的规则。

更大的模型或更长的上下文窗口可以提高上限，但并不会改变根本限制。注意力是有限的，并且要被所有 token 共享；模型也很容易在长上下文中丢失中间部分的信息，也就是所谓的“lost in the middle”效应；而且每一步都会受到上一步的影响，所以早期的一点偏移会不断累积。更大的窗口只是把墙推得更远，并没有让墙消失。

于是，问题不再是“如何让一个 Agent 记住更多”，而是变成了：如果从一开始就不需要任何单个 Agent 记住全部内容呢？

如何设计一个始终贴合规格的多 Agent 系统

给每个 Agent 分配自己的职责，防止上下文窗口漂移

想想一个高效的软件团队是如何交付代码的。没有人会把整个项目都装在自己脑子里。有人负责梳理代码库，有人负责实现功能，有人负责视觉呈现，有人负责检查工作顺序，避免两个改动互相冲突。

我们设计的 Agentic 系统也是同样的方式：把问题拆开，交给不同的专家处理。每个专家只负责一件事，而且这个任务足够小，可以放进上下文窗口里，并留出足够空间进行推理。

我们的核心 Agent 团队

Agent	负责内容
Code Cartographer	阅读代码库，梳理包结构，发现可复用的模式和可接入的缝隙
Engineering Alchemist	审查代码架构
Visual Stylist	塑造界面，使其符合规格中的意图
Ticket Auditor	保持工作顺序正确，确保并行改动不会相互冲突
Review Agents	进行代码质量评审，运行完成后的应用，录制演示视频，并附上验证证据

完整的阵容中还可以包含更多专家。你可以先从少数几个开始，在遇到协作瓶颈时再增加更多角色。同时，也要根据底层模型的选择和能力强弱来取得平衡。

通过锚定 Jira 来提升稳定性和 Agent 协作性

一开始，我们只用一组专家 Agent 和本地 Markdown 文件来管理计划和状态，但这种方式并不稳定。Agent 本身是有能力的，但工作会被错误地提前执行，进度也难以衡量。如果会话意外结束，就很难判断计划执行到了哪里，也很难恢复工作。

为了安排 ticket 的顺序并组织工作流程，我们需要一个共享的跟踪系统。

为什么选择 Jira？因为看板不只是一个任务追踪器。

Jira 是一个依赖关系有向无环图。Issue 之间的链接会自然绘制出关键路径，因此调度器可以知道哪些任务可以安全并行运行。前置任务未完成之前，后续任务不会启动。

工作项本身就是提示词。任务描述加上验收标准，就是一个自包含、带版本的上下文包。这就是我们所说的“把工作项当作提示词”。

状态、审计和人类参与都是内建的。Jira 拥有原子化的状态流转，可以处理并发 Agent；历史记录提供审计轨迹；人也可以在同一个 Agent 读取的看板中重新排列优先级，让 human-in-the-loop 始终存在，在 Agent 无法判断时提供人的判断。

	本地 Markdown 文件	Jira 看板
工作顺序	隐含	明确
工作进度	无法判断进度，因此难以恢复工作	持久状态随时可访问，易于衡量进度并恢复工作
任务分配	不清楚每项任务由谁负责，是 Agent 还是人	每个 ticket 都有负责人字段，所有人可见
规模	上下文中的待办列表会漂移；对单个窗口来说过大	看板可以处理数百个 ticket，而不会退化
评论与标签	没有原生支持；添加元数据会污染规格说明	评论、标签和历史记录与工作描述相互分离
协作	无法在不污染规格说明的情况下协作、评论或更新顺序	从评论到优先级更新，协作都很容易
审计轨迹	除非自己搭建，否则没有	拥有完整的工作历史
自动化与工作流	没有内建触发器，所有衔接逻辑都要自己写	工作流规则和 webhook 可以在工作状态变化时触发，启动下一步或新的 Agent 工作

用 daemon 而不是 Agent 来编排，才能实现可靠调度

一种编排方式，是让一个聪明的 Agent 来负责全局调度，并调用其他 Agent 或子 Agent。我们尝试过这种方式。但风险在于，编排者本身也是一个 Agent。那个本该让所有人保持在轨道上的东西，也会发生漂移。一旦顶部发生晃动，下面的工作 Agent 也会被连带影响，错误会被放大。

我们仍然保留了一个编排 Agent，但一部分工作被内建到工具中，也就是 daemon。daemon 是确定性的，它把原本需要靠推理完成的上下文工作卸载出去，同时也减少了初始启动时的调度开销。

daemon 不会漂移，因为它并不进行推理，这也意味着它不会消耗 token。它是一段固定代码，每一次 tick 都做同样的事：读取看板，找出阻塞项已完成的 ticket，然后派发它们。相同的输入，得到相同的决策，每一次都是如此。

daemon 就像重力。 工作 Agent 可能会在任务中途游移，但 Jira 看板是系统的基准状态，而 daemon 的下一次读取会把系统重新拉回这个基准。无论一次运行如何结束，下一次决策都来自持久化的看板状态，而不是上下文窗口。这样，系统会收敛，而不是让错误不断叠加。

足够好的模型未来能否可靠地完成编排？也许可以。但智能往往要在可预测性和成本之间权衡，而调度并不需要创造力，也不需要巨大的上下文。它只需要每一次都正确。

所以，我们把 Agent 的智能用在真正需要判断力的地方，也就是工作本身；而把协调工作交给廉价、确定性的代码来负责。

如何搭建你自己的专家 AI Agent 团队

分四步：

1. 把一切锚定到 Jira 看板

把计划放到看板上：每个工作单元对应一个 ticket，并通过 issue links 表达依赖关系。这些链接就是你的依赖图，因此你不需要再写一个规划器。这个看板现在就是要构建什么、以及以什么顺序构建的唯一事实来源。

2. 运行一个监听看板的 daemon

写一个小 daemon，一个 cron 循环就足够。它会轮询看板，查找那些处于 To Do 状态、且所有阻塞项都已经 Done 的 ticket。这个查询就是你的调度器。

对于每一个准备就绪的 ticket，daemon 会把它移到 In Progress，这相当于加锁，确保任务不会被重复执行，然后再把它交给 Agent。

3. 给 Agent 配置可以调用的角色人格

列出你希望团队中拥有的成员，每个人只负责一项工作，并把每个成员做成父 Agent 可以调用的子 Agent。可以先从三个角色开始：

Designer，负责产品和 UX 意图；Builder，负责编写代码；QA，负责根据规格进行验证。

只把 ticket 描述和验收标准传给子 Agent。一个全新的上下文窗口，加上一项明确工作，正是防止漂移的关键。

4. 回报结果，让循环继续推进

当子 Agent 完成工作后，它会在 ticket 上评论自己的 diff 和演示说明，并把 ticket 移到 Done。下一次 tick 时，daemon 会看到新解除阻塞的 ticket，并派发它们。这样，循环就能自行运转。

你会从看板中免费获得审计轨迹、工作顺序和可查看的验证证据。

但仍然要让人在回路中。真正的收益不是让审查者消失，而是把数小时的调查，变成几分钟查看一件已经完成的事情。