Long-running Agent 研发实践 · 上篇
随着 AI Coding Agent 能力不断增强，代码生成不再是许多开发任务中最主要的限制。需求分析、代码编写、测试生成、故障排查、代码审查，AI 都能承担一部分，开发者也可以同时运行多个 Agent，让它们在不同任务上持续推进。
但更快地生成代码，并不意味着软件能更快、更可靠地交付。当项目变大、任务依赖增加、多个 Agent 并行工作时，新的问题开始出现：
- Agent 如何在长期任务中持续遵守已经确认的需求与技术约束？
- 一项任务究竟是代码完成、已经集成，还是通过了最终验收？
- 会话结束、上下文丢失后，新的 Agent 如何准确接续此前的工作？
这说明 AI 辅助开发的核心挑战，正在从单次代码生成，扩展到整个研发过程的组织与控制。OpenAI 的 Harness Engineering，以及 Anthropic 的 Effective Harnesses for Long-Running Agents、Building Effective Agents 等文章，都指向同一个方向：提升 AI 软件开发能力，不仅需要更强的模型，也需要与之匹配的工程组织方式。
本系列分两篇，讨论一种 Human-Led Multi-Agent Workflow（人类主导的多 Agent 协同研发工作流）。它不是固定的软件框架，也不要求特定数量的模型，而是一种以人类决策为中心，通过职责分离、外部化工程状态、隔离执行和分层验证来组织 AI 开发的方法。上篇讲分工与流程，下篇讲 Harness 与可校准信任。
全系列围绕三个原则：
- 设计意图与工程事实分离。 需求和技术合同定义系统应该如何工作；代码、Git 状态和运行证据反映系统目前如何工作。
- 实现、集成与验收分离。 代码写完、进入目标分支、通过最终验收，是三种不同的工程状态。
- 流程约束与技术强制分离。 Agent 指令能规范行为，但可靠的权限边界仍需要工具和运行环境保障（下篇展开）。
01｜为什么单 Agent 难以覆盖长期复杂项目
单 Agent 适合原型开发、局部功能和范围明确的短期任务：需求、实现和验证集中在一个会话里，沟通成本很低。但当同一个 Agent 长期兼任产品讨论、架构设计、编码、测试、审查和集成时，三个问题会逐渐显现。
上下文稀释。 长期项目会积累大量信息：产品决策、技术约束、历史实现、错误记录、测试结果。它们的重要性并不相同，有的只是临时讨论，有的已经过时，有的则是后续必须遵守的正式要求。当这些内容混在不断增长的对话里，Agent 很难准确区分。上下文压缩能缓解窗口容量，却无法保证关键工程状态被完整保留。Anthropic 也指出，长周期 Agent 需要借助进度文件、Git 历史等外部机制来跨会话接续，而不能只依赖对话。
范围漂移。 Agent 在解决问题时可能主动扩大修改范围：为修一个局部界面问题重构共享业务逻辑，或为了让测试通过改变既有系统行为。这些修改未必是低质量代码，却可能偏离产品目标。技术上合理，不代表产品上正确。因此，任务不仅要说明做什么，还要说明允许改哪些范围、哪些规则必须保持不变、哪些决策需要重新获得人类确认，以及用什么证据证明完成。
工程状态失真。 Agent 能写出很详细的完成总结，但自然语言报告本身不是工程证据。一次任务可能通过了局部测试，却还停在独立分支里；一个功能可能已经合并，却没做过端到端验证。如果开发状态主要靠聊天总结维护，就容易把“Agent 认为完成”误判为“工程已经完成”。
归结起来，长期开发要解决两件事：让工作可以跨会话恢复，让交付可以根据独立证据验证。
02｜基于职责而非数量的三层分工
多 Agent 协作不应理解为同时打开多个 AI 编码窗口。Agent 数量增加，可能提高局部吞吐量，也会带来更多的任务协调、共享资源竞争和集成成本。更重要的是建立明确的责任结构：
决策层（Human + AI）→ 编排层（Main Agent）→ 执行层（Execution Agents）
这里的 Agent 指承担不同职责的 AI 工作实例或会话，不一定对应独立模型，也不要求所有角色持续运行。
决策层：确定目标和边界。 人类可以借助 AI 分析需求、比较方案、识别设计冲突，但关键产品决策、重要架构取舍和高风险操作授权，最终由人类负责。这一层的核心产物是经过确认的设计意图，包括产品需求、业务规则、技术约束和验收要求。需要特别区分“正在讨论的方案”和“已经批准的决策”，否则后续 Agent 可能把早期的探索性意见当成正式要求。
编排层：组织工程过程。 Main Agent 接收已确认的目标，结合仓库状态、已有实现和任务依赖，把目标转化为可执行的任务，负责任务拆分、依赖分析、范围控制、交付检查和集成准备。它应当根据真实代码状态判断开发缺口，而不是根据历史聊天推断系统现状；它可以发现需求冲突并提出建议，但不应自行改变已确认的产品目标。
执行层：完成边界明确的任务。 Execution Agent 负责代码实现、必要测试和范围内的缺陷修复。相对独立的任务可以分给不同的执行 Agent 和工作区；而对于跨越界面、业务逻辑和测试的完整功能，通常更适合由同一个执行责任方完成，而不是机械地按文件类型拆给多个 Agent。拆分的依据是交付责任的完整性。
这与 Anthropic 在 Building Effective Agents 中介绍的 Orchestrator–Workers 模式有相似之处，区别在于这里更强调长期工程状态、人工决策权限和交付的验证边界。独立的 Review Agent 可以作为横向审查角色存在，不必构成第四个固定层级。三层是一种职责划分方法，而不是必须严格部署的系统架构。
03｜从需求到验收：可验证的七步闭环
分工解决“谁来做”，还需要明确任务在不同阶段如何流转：
需求确认 → 状态核查 → 任务编排 → 隔离执行 → 证据验证 → 授权集成 → 状态更新
Step 1 需求确认。 开发前先明确目标行为、业务约束和验收条件。对未确定的需求，AI 可以辅助分析方案，但讨论过程不等于批准的实现要求。复杂任务应形成相对稳定的需求文档或技术合同，让执行依赖明确的依据，而不是不断变化的聊天记录。
Step 2 状态核查。 规划任务前，Agent 要重新检查真实工程环境：当前 Git 基线、已有代码、相关测试、未集成的修改和已有的交付证据。这里要分清两个概念：
- Design Intent（设计意图）：规定系统应该实现的目标行为。
- Engineering Reality（工程事实）：由当前代码、版本记录、构建产物和运行结果证明的实际状态。
两者不一致时，应当记录并分析差异，而不是直接认定某一方正确。可能是文档没跟上最新实现，也可能是代码偏离了正式要求，具体如何修正，要看决策记录和实际证据。
Step 3 任务编排。 拆分任务的目标不是最大化并发数量，而是减少不必要的协调与返工。适合并行的任务通常边界清晰、共享依赖少、能分别验证；涉及共享业务逻辑、数据库、构建目录或测试环境时，需要明确资源归属，并按风险选择隔离或串行。整体交付效率，比同时运行多少个 Agent 更重要。
Step 4 隔离执行。 执行 Agent 在明确范围内开发。Git Worktree 能为同一仓库中的不同任务提供独立工作目录，减少代码修改之间的干扰。但它只隔离代码工作区，数据库、端口、后台进程、构建缓存等共享资源仍可能冲突，需要另行设计隔离。同时，代码完成不应被自动解释为获得了部署、迁移或操作生产数据的权限。
Step 5 证据验证。 Agent 的完成报告只是审查入口，真正的验证应依赖可检查的证据：Git Diff、测试结果、构建记录、实际运行行为和验收条件。验证强度随风险调整：低风险修改侧重代码差异与局部测试；中风险修改要覆盖受影响模块和调用路径；高风险修改则要重点检查数据完整性、权限、失败路径和迁移。较复杂的修改可以引入独立 Review Agent，减少实现者自我评价的局限，但 Agent 审查仍是模型判断，不能取代实际测试或安全控制（下篇展开）。
Step 6 授权集成。 代码通过任务级验证后，还要检查待集成修改的来源、Git 基线、差异范围和授权条件。进入目标分支后，结果可能与原独立工作区不同，例如共享代码的变化引入接口不兼容，或使原本通过的测试失败。所以任务级验证与集成级验证要明确区分，关键功能在集成后还应验证完整的用户流程，而不是只相信原执行 Agent 的测试结论。
Step 7 状态更新。 开发状态应根据证据维护，而不是根据 Agent 的文字总结更新。至少要区分三个维度：已实现、已集成、已验收。
三者相互关联，但不能互相替代：功能已集成，不代表已通过验收；未通过验收，也不一定意味着代码没写完。有了这个模型，新的 Agent 接手时才能准确判断：该继续开发、修复缺陷，还是执行尚未完成的验证。
04｜局限与适用条件：更多 Agent 不一定更高效
这套工作流增加了任务组织、状态管理和验证成本，并不适合所有任务。小型原型、简单脚本、边界明确的局部修改，单 Agent 往往已经足够。只有当项目具有长期上下文、多模块依赖、多个相对独立的任务，或较高的工程风险时，职责分离和外部化状态管理才可能带来明显价值。
多 Agent 的成本也不只是模型调用费用，还包括任务协调、工作区维护、冲突解决、审查和集成时间。如果任务高度耦合，并行开发产生的返工可能比串行执行更多。
评估这类工作流，不应只看代码生成速度或完成的任务数量，还需要关注更能反映端到端交付质量的指标。
需要说明的是，这些指标是后续评估的方向，不是已成立的效率结论。本文所述方法来自工作流设计与个人工程实践，并没有经过控制实验验证，实际收益仍要结合项目复杂度、协调成本和交付质量来判断。只有端到端交付收益超过协调、验证和维护成本，多 Agent 才真正具有工程价值。
结语
当 AI 能承担越来越多的实现工作，开发者需要投入更多注意力的，可能不再只是如何表达编码需求，而是如何定义正确的目标、组织任务、维护工程状态，以及验证最终结果。Human-Led Multi-Agent 提供的，是一种用职责边界和状态分离来应对这一转变的思路。
但分工只解决了一半问题。如果工程知识仍然只存在于某一次聊天里，多 Agent 只是把单窗口问题搬到了编排层。下篇将讨论如何用 Harness 让这套流程在会话丢失后仍能恢复，以及如何建立对 Agent 的可校准信任。
参考资料
- OpenAI. (2026). Harness engineering: Leveraging Codex in an agent-first world.
- Anthropic. (2025). Effective harnesses for long-running agents.
- Anthropic. (2024). Building effective agents.
- Anthropic. (2026). The AI-native SDLC playbook.