摘要长任务 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 才能从代码生成工具变成可验证的研发任务执行系统。推荐阅读当 LoRA 变成 Agent 工具模型会不会开始管理自己的长期记忆好的 AI 办公应用不是聊天框而是能跑完流程OpenSpaceAgent 真正该进化的是 Skill 层DeepSeek Harness 的价值不在 Loop而在运行时组合Agent 运行时不是聊天流而是给 LLM 补操作系统
