摘要：长任务 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、多个服务、多个系统边界和多个发布阶段。
正确做法是先把它拆成一片森林里的多棵树。
推荐链路是：
人划森林，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 才能从代码生成工具变成可验证的研发任务执行系统。 
推荐阅读
当 LoRA 变成 Agent 工具：模型会不会开始管理自己的长期记忆
好的 AI 办公应用，不是聊天框，而是能跑完流程
OpenSpace：Agent 真正该进化的是 Skill 层
DeepSeek Harness 的价值不在 Loop，而在运行时组合
Agent 运行时不是聊天流，而是给 LLM 补操作系统
