当 AI 开始替我写代码，我却逐渐成了 AI 之间的人肉传话筒。
最开始，我觉得这套协作模式非常合理。
在网页端和 AI 讨论需求、推演架构，让它生成一份详细的执行指令。然后把指令复制给 Code Agent，让它读取仓库、修改代码、运行测试。执行完毕后，再把报告贴回网页端，让 AI 审查结果、判断下一步该做什么。
网页端 AI 负责动脑，Code Agent 负责动手，我握有最终决策权。分工明确，看起来既高效又可控。
起初，这套方式确实帮我完成了不少开发工作。
但随着项目规模扩大，一个奇怪的现象出现了：
AI 写代码的能力越来越强，而我花在协调 AI 上的时间却越来越多。
直到最近，我重新翻看了项目中近 100 条 Agent 执行任务记录，才意识到问题可能并不在模型能力，而在于我组织 Agent 工作的方式。
一、一个功能，为什么需要十几个 Agent 任务？
在这近 100 条任务记录中，有一组关于 Settings 的开发任务特别典型。
仅仅围绕一个设置模块中的语言持久化功能，就衍生出了二十余条相关任务。
从共享接口准备、功能实施、独立审查，到本地提交、集成预检、合入主分支、推送前审计，再到最终推送。
如果中途遇到测试失败，还会继续分叉出修复、整改复审、阻断项验收等新任务。
更有意思的是，这些任务单独看，每一个似乎都很合理。
代码需要审查，测试需要验证，合并需要谨慎。涉及数据库、生产环境和真实用户数据时，严格的检查更是必不可少。
但当这种完整流程被不断复制到每一个局部改动上，问题就出现了。
一个 Agent 完成实现，另一个 Agent 负责审查；审查发现问题，再启动 Agent 修复；修复完成后，重新安排独立复审；通过后，还要让网页端 AI 判断是否具备提交和集成条件。
完成一个任务，往往只意味着可以开始下一个流程任务，而不是交付了一项新的产品能力。
任务数量不断增加，报告越来越规范，PASS 和 APPROVED 越来越多。
可用户真正能够使用的新功能，并不会因为这些标签增加而同步增长。
当然，仅凭任务记录不能断言每一次检查都是多余的。但这种现象让我开始反思：我们究竟是在提高软件开发的可靠性，还是在不断增加证明自己可靠的程序？
我们可能正在用 AI，以极高的速度制造新的管理工作。
二、看不见真实代码，就容易用流程弥补不确定性
这套协作模式最大的问题，不是网页端 AI 不够聪明。
而是网页端 AI 与真实工程环境之间存在天然的信息断层。
它通常无法直接观察本地仓库的实时状态。
不知道某个文件是否刚刚被修改，不知道当前分支是否与主线冲突，也不能独立确认一项测试到底有没有通过。
它对项目的理解，主要来自我复制过去的执行报告。
而执行报告终究不是工程事实本身。
一次代码修改可能涉及多个文件、一组隐含依赖，以及执行过程中临时作出的技术判断。但这些信息经过 Agent 总结、人类转贴和网页端 AI 再次归纳后，往往只剩下一段看似完整的文字。
信息每经过一次转述，就可能发生一次上下文折旧。
更麻烦的是，当 AI 无法直接验证工程事实时，它往往会通过增加流程约束来降低判断的不确定性。
于是，原本可能由一次测试解决的问题，逐渐变成：
测试报告 → 独立审查 → 审查复核 → 阶段验收 → 下一轮执行授权。
不确定性没有真正消失，只是被转化成了更多管理动作。
这很容易形成一个循环：
信息不完整 → 增加验证 → 产生更多报告 → 上下文进一步稀释 → 再次增加验证。
而我，就是维持这个循环运转的人。
我每天把一个 AI 的指令发给另一个 AI，再把后者的结果转述给前者。哪个 Agent 需要什么上下文、哪个审查已经通过、哪个任务还存在阻断，都需要我不断跟踪。
最初我以为自己是在指挥一支 AI 开发团队。
后来发现，自己更像是它们之间一条带宽有限、成本高昂的人肉通信总线。
代码执行实现了自动化，任务之间的协调却依然高度依赖人工。
三、长对话最大的陷阱：它让你误以为项目状态始终连续
为了减少反复解释项目背景的成本，我曾尝试让网页端 AI 长期管理同一个项目对话。
需求、架构决策、Bug 讨论、代码审查、历史报告，全部放进去。
当时的想法很简单：既然 AI 能处理长上下文，那么保留越多历史，它应该越了解我的项目。
但实际使用中，我逐渐发现，长对话并不天然等于可靠的项目记忆。
最常见的是以下三种状态失真。
1. 废案污染
某个技术方案明明已经被推翻，但旧讨论仍然留在上下文中。
当后续问题与这个方案相似时，AI 可能重新引用它，甚至把已经废弃的设计当成当前约束。
下面两张截图都是真实发生过的案例：
2. 临时方案被误认为长期规范
为了修复一个局部 Bug，我们可能采用临时的 Workaround。
但经过多轮讨论和总结，这个只适用于特定情境的解决方法，有时会被 AI 误认为全局设计原则。
原本为了快速解除阻断的权宜之计，反而可能成为后续开发的额外限制。
3. 最危险的压缩漂移
假设一个阶段原本需要完成 A、B、C 三个模块。
开发过程中，模块 A 的局部测试通过了，Agent 返回 PASS。
这本来只说明 A 已经满足当前验收条件。
但经过几轮阶段总结和上下文压缩，原本的限定条件可能逐渐丢失。
最后，某次摘要把“模块 A 验收通过”概括成“当前阶段目标已完成”。
还没有完成的 B 和 C，就这样从后续工作描述中消失了。
这个例子揭示的风险，不仅是 AI 会遗漏信息。
更危险的是，AI 可能把不完整的信息重新组织成一个看似自洽、语气确定的结论。
人很容易相信这种结论，因为它逻辑通顺，结构清晰，而且似乎继承了之前的所有讨论。
长对话因此制造了一种虚假的连续性。
你以为 AI 记得整个项目，但它可能只是记得一份不断被重新解释的项目摘要。
连续的聊天记录，不等于连续、准确的工程状态。
四、真正需要改变的，不是 Prompt，而是工作流
经历这些问题后，我开始怀疑一种看似合理的思路：
只要把 Prompt 写得足够详细、把任务拆得足够细、把审查要求写得足够严格，就能稳定驾驭复杂的 Agent 开发。
我曾经也倾向于这样做。
为了避免遗漏，把每个执行步骤写清楚；为了避免出错，增加独立审查；为了确保安全，在每个阶段之间设置明确的 Gate。
但后来我发现，这种方式很容易把人和 Agent 一起困在流程里。
再精密的 Prompt，如果始终建立在二手信息之上，也只是在对不完整的工程事实进行更复杂的推理。
真正需要改变的不是 Prompt，而是控制流本身。
首先，开发闭环应该尽量留在真实工程环境中。
Agent 应该能够直接读取代码、识别项目约束、执行修改、运行测试，并根据验证结果继续调整。
对于普通的低风险任务，不应该每修改一个函数、每完成一次测试，都要返回网页端重新请求下一条指令。
其次，应该根据风险决定审查强度，而不是让所有任务接受相同的流程。
真实数据库迁移、生产部署、权限变更等操作，当然需要严格的审查和人工确认。
但局部 UI 调整、低风险 Bug 修复和常规重构，完全可以采用更轻量的验证方式。
没有风险分级的工作流，形式上越严密，工程上可能越迟钝。
不过，我认为最重要的改变还不止于此。
不要只把下一条指令交给 Agent，要让它对一个目标负责
即使把所有 Prompt 从网页端搬进终端，如果我仍然要求 Agent 每执行一步就停下来汇报、等待批准，那么问题并没有真正解决。
我依然是那个负责安排每一步动作的人。
区别只是复制粘贴的距离变短了。
传统的指令接力模式，本质上是：
人类规划一步 → Agent 执行一步 → 人类检查并规划下一步 → Agent 再执行一步。
而我更期待的 Agent 工作方式是：
人类定义目标、约束和验收标准 → Agent 在授权边界内自主实施与验证 → 异常或高风险操作交还人类决策 → 人类验收最终成果。
这两种模式的核心区别，不在于 Agent 有没有自主编写代码，而在于人类是否仍然承担每一个中间步骤的编排工作。
人类应该负责判断什么值得做、哪些工程边界不可跨越、最终结果是否满足真实需求。
至于中间需要修改多少次代码、运行多少次测试、修复多少个局部问题，应该尽可能由 Agent 在可控范围内自行完成。
这才是我理解中更有价值的 Agentic Workflow。
当然，这并不意味着让 Agent 无限制地自主运行。长期任务同样需要清晰的权限边界、可靠的状态持久化、可恢复的执行机制和必要的人工干预点。
如何真正建立这样的工作流，是另一个更大的工程问题。
我会在后续发布的 《Long-running Harness》 系列文章中，继续分享我对长期运行 Agent、任务状态管理、执行闭环和多 Agent 协作的实践与思考。
最后
回头看，我并不觉得最初使用网页端 AI 编写指令是一个错误。
对于探索性开发、小型项目，或者刚开始使用 Code Agent 的阶段，这种方式足够直观，也确实能够帮助开发者快速上手。
但随着项目进入长期迭代、多分支协同和持续集成，这种依赖人工转述上下文的模式，其局限性会越来越明显。
那近 100 条 Agent 任务记录并不意味着没有产出。它们解决了真实的工程问题，也帮助我推进了项目。
但它们同时提醒了我一件事：
任务执行得越来越自动化，不代表整个开发过程就越来越自动化。
如果每一次自主执行的背后，都需要人类发起下一轮协调，那么我们自动化的可能只是执行环节，而不是工作流本身。
现在，我不再用启动了多少个 Agent、消耗了多少 Token、完成了多少条任务来衡量 AI Coding 的效率。
我更关心一个简单的问题：
今天，我究竟交付了多少真正有用的东西，又花了多少时间在向 AI 解释另一个 AI 的工作？
如果后者开始占据大部分时间，那么无论模型多么强大、任务报告多么漂亮，这套工作流都值得重新设计。
好的 Agent 系统，应该减少人类需要亲自协调的工作，而不是让人类成为一群 AI 的全职项目经理。