长任务 Coding Agent 的关键不是写代码，而是交付链路

摘要：长任务 Coding Agent 的成熟标志，是按状态推进研发任务、按证据交付、按失败类型回流。它需要 Agent Runtime、Workflow System 和 Evidence System 一起工作。

长任务的难点是持续推进

短任务里，Agent 写对一个函数、补一段测试、解释一段代码，就已经很有价值。

图：长任务 Coding Agent 需要围绕证据推进完整交付链路

长任务要做更多事：先弄清需求边界，再找到代码入口，理解接口、字段、状态机、存储、消息、事务边界之间的关系。中间还要生成方案、等人确认、改代码、跑测试、处理失败、过评审、沉淀证据。

这类任务不能只靠更长的 prompt，也不能把希望全押在更强的单点 coding agent 上。

它需要一套研发任务运行时：模型负责推理，Skill 负责原子动作，Workflow 管流程，Condition 管准出。

Loop 管失败回流，Trace 和 Evidence 管证明，人类只在关键 Gate 做决策。

普通 coding agent 适合边界清楚的局部修改。比如修一个明确 bug、补一个测试用例、解释一段逻辑、改一个函数。这类任务上下文短，状态少，失败后人很容易接管。

长 coding 任务的风险在另一层：

短任务关注点	长任务新增压力
单次代码生成质量	多阶段状态能否持续保存
工具调用是否可用	每一步是否有准出条件
修改是否正确	影响面是否被完整识别
测试是否通过	失败后该回到哪一步
人工兜底	人应该在哪些节点做决策

所以长任务 Agent 要解决的核心问题，是稳定推进一条研发链路，并证明自己做完了。

把聊天变成研发流程

一个可落地的长任务 Agent，不应该被设计成单一聊天窗口，而应该被设计成三层系统。

层	职责	重点
Agent Runtime	调模型、Skill、MCP、CLI、代码仓库、测试环境和研发系统	让 Agent 在受控边界内执行
Workflow System	定义阶段、状态、准出条件、失败回流和人工确认点	让任务按流程推进
Evidence System	保存需求、方案、代码变更、测试结果、评审结论和失败记录	让交付可验证、可复盘

这套结构的目标很朴素：Agent 在每个阶段内尽量自主执行，跨阶段推进必须有明确条件。不能让模型自己觉得“差不多完成了”，也不能让状态散落在上下文、prompt 和临时代码里。

知识树避免上下文污染

长 coding 任务不是资料越多越好。传统知识库容易把过时文档、低相关内容和不可验证信息一起塞进上下文，反而拖累判断。

更稳的方式是知识树。

层级	存什么	谁维护
树根	PSM、仓库、目录、技术栈、Usecase 到代码入口映射	人维护，保持少而准
树干	API IDL、RPC IDL、DB Schema、MQ 事件、状态机、事务边界	人和工具共同维护
树叶	字段影响面、调用链、异常分支、上下游关系、实现细节	Agent 按任务动态切片

人维护稳定高价值的树根和树干，Agent 在当前任务里长出树叶。这样既给模型足够的方向，又不会把易过期的实现细节变成手工维护负担。

动态切片是这套方法的关键。它要围绕当前需求做正向和反向追踪：这个字段会影响哪些下游，这个状态由哪些上游决定，改这个接口会牵动哪些契约。

Agent 方案质量很大程度取决于这一步，而不是取决于它读了多少无关文档。

Workflow 把状态转成显式契约

原型阶段可以靠 Driver Skill 把流程串起来：澄清需求、读代码、写方案、等确认、实现、测试、修复、提交证据。

Driver 跑久了会有维护问题。状态可能藏在 prompt 里，准出条件写在临时代码里，失败回流靠 Agent 自己判断，安装资产和文档说明还要同步改。规模一大，系统会变脆。

成熟形态应该把这些隐式共识转成 Workflow 契约：

对象	回答的问题
Workflow	任务应该怎么走
Condition	什么事实证明当前阶段完成
Loop	出问题后回到哪里
Trace	过程发生了什么，为什么这么做
Evidence	结果凭什么可信
Card	当前在哪一步，谁需要确认

Agent 的自由度仍然存在，但应该被限制在单个阶段内部。跨阶段推进、失败回流和验收证据，要由系统规则承载。

Human Gate 只做关键判断

长任务 Agent 不应该追求全程无人干预。更现实的目标是 Agent 主导执行，人类关键把关。

人应该出现在这些节点：

类型	节点
边界判断	需求边界确认、Usecase 拆分确认、共享契约确认
技术判断	技术方案选择、高风险改动批准、测试结果验收
交付判断	代码合入判断、发布节奏和回滚策略决策

每个 Gate 都应该有结构化输入：背景、候选方案、推荐选项、风险说明和需要做出的选择。

人不需要被拉进流程陪聊，只需要在高价值、高风险、不可逆的位置承担决策责任。

大需求先拆森林，再跑单棵树

大型需求不适合直接交给 Agent 一口吞下。它通常涉及多个角色、多个 Usecase、多个服务、多个系统边界和多个发布阶段。

正确做法是先把它拆成一片森林里的多棵树。

推荐链路是：

建立 Forest Map：明确项目目标、业务范围、角色、系统、Usecase 列表和风险区域
形成 Usecase Tree List：把大需求拆成多个中小需求树
建 Dependency DAG：标注树与树之间的前置依赖、共享字段、共享 Schema、发布顺序和回滚影响
给每棵树生成 Treeloop Card：进入单树的长 coding 任务 Agent loop

人划森林，Agent 跑树。人负责边界、依赖、共享树干和风险排序；Agent 负责单棵树里的澄清、方案、实现、测试和证据。

按 Usecase 拆通常优于按模块拆。模块是代码组织单位，Usecase 才是交付单位。

按模块拆容易让每个任务只完成局部改动，集成时才发现业务链路没跑通。按 Usecase 拆，每个任务都能对应完整目标、主流程、异常流和验收条件。

失败回流不要把失败当中断

长任务里失败是常态。测试失败、方案被否、评审阻塞、需求变化、环境不可用，都不该只触发“重试一次”。

系统要先判断失败类型，再选择回流点：

失败类型	回流位置
需求边界变化	需求澄清
方案不被接受	方案设计
评审指出实现问题	代码实现
测试发现代码问题	编码与测试
测试暴露方案缺陷	方案设计
环境不可用	环境检查

每次失败都应该留下原因、影响范围、建议回流点和下一步动作。这样失败不会只消耗上下文，它会变成任务收敛的一部分。

建设路径：从 Skill 到 Client

这类系统不能一开始就做成大平台。更稳的路线是逐步长出来。

阶段	目标
Skill	沉淀需求澄清、代码定位、动态切片、方案生成、测试执行、评审检查等原子能力
Driver	把稳定 Skill 串成可运行开发 loop，验证端到端链路
Trace	记录真实任务中的输入、输出、失败、人工确认和产物
Workflow	把稳定阶段、Condition、Loop、Evidence 和 Card 固化成规则
Client	把最佳实践沉淀为可维护、可版本化、可交付的研发任务运行时

从 Skill 到 Driver，是从点到线；从 Driver 到 Workflow，是从经验到规则；从 Workflow 到 Client，是从实践到系统。

结语

长任务 Coding Agent 的成熟标志，是能把研发任务按状态推进、按证据交付、按失败回流。

它不靠更长的 prompt，也不靠更强的单点 coding agent。它需要围绕研发任务构建工程化运行时。

AI 负责连续执行，人负责关键判断；AI 处理动态树叶，人维护稳定树根和树干。

只有这样，Agent 才能从代码生成工具变成可验证的研发任务执行系统。

AI小老六