AgentScope 2.0：长周期 Agent 的失败不在单次回答，而在任务、信息和动作缺少统一机制

AgentScope 2.0 团队在最新的技术定位文章中描述了一类具体失败场景：模型正确理解了漏洞公告，却因为没看到项目约束而升级了错误的依赖；写出了正确的补丁，却在上下文压缩后忘记测试；完成了检查，却把旧代码关联的测试报告当成了当前版本的证据。这些问题的共同点是，每一次单独回答都没有错，但整条任务链走偏了。团队的判断是，仅仅提升单次回答质量无法解决这类跨步骤的结构性失败。

他们据此提出了一个工程层次上的区分：框架（Framework）提供模型、工具、消息和状态等抽象，回答的是怎么构建；运行时（Runtime）提供调度、持久化和事件投递等基础设施，回答的是怎么运行；而 Harness 回答的是如何让模型在整个任务过程中有效工作——它不是组件的集合，而是已经协同运转的机制，包括怎样向模型供给信息、怎样推进任务、怎样调用工具、怎样保存进度、怎样让人参与执行。

Harness 的机制被组织为三层。任务层解决持续进展的问题：执行状态通过 AgentState 持久化，任务列表由 todo_write 更新，模型在每一步推理时接收当前进度的投影，而非从数百条历史消息中重新推断走到哪里了。计划模式（Plan Mode）把规划阶段变成可执行的约束——进入后通用修改工具被阻断，只保留只读工具和计划协作工具，退出时进入人工确认。子 Agent 提供上下文隔离，让依赖树、长日志和候选方案在子任务中探索，主 Agent 只接收结论和证据引用。

信息层解决有限窗口内的组织问题。工具结果卸载把完整内容存入外部文件，活跃上下文中只保留紧凑表示和引用路径；历史压缩保留任务目标、关键决策、未解决问题和续接点，同时保留近期交互的原文。两者都配合结构化状态工作——Todo 项、权限模式和验证摘要从当前状态重新投影，而非依赖模型总结旧对话。上下文构建被做成显式管线，产生一份 Context Manifest 记录来源标识、内容版本、预算和变换信息，使模型看到什么成为可检查的工程行为。

动作层解决执行控制与可信反馈的问题。工具调用表达的是意图，实际执行前系统必须验证参数、绑定身份、评估权限并获取必要的人工确认。权限机制支持 ALLOW、DENY 和 ASK 三种模式，与计划模式结合后，任务阶段本身也影响哪些动作可执行。Tool-In-Sandbox 模式将编排与执行分离：服务端的 Harness 发起工具调用，沙箱执行后返回结果和工件，Harness 继续推理和推进任务。执行反馈不依赖自然语言日志猜测成功，而是保留结构化事实——Shell 直接提供退出码和输出截断信息。

文章用了一个贯穿三层的示例：分析支付服务的高危依赖漏洞、完成修复和验证、准备待审批的变更文档，当前授权范围不含生产发布。这个例子展示了三层如何协作——任务层区分目标（修复漏洞并准备文档）、进度（集成测试正在运行）和已验证事实（此补丁通过了指定版本的测试）；信息层把扫描报告卸载到外部文件，只在上下文中保留阻塞问题列表；动作层确保创建变更文档和发布到生产是两个独立授权的业务动作，计划审批不自动延伸为发布授权。

不过需要指出，这是厂商对自身产品架构的阐述，不是独立验证的结果。文章明确承认，现有的执行观测和局部确定性检查并不意味着框架已经默认执行整个业务任务的自动验收——检查对象、验收标准和验证器仍需调用方显式指定，统一的完成门控仍待开发。Harness 的定义也可能被视为对已有工程实践的重新命名：状态持久化、上下文管理、沙箱隔离这些机制，许多团队在构建内部 Agent 系统时已经各自实现。其真正的增量价值取决于能否降低重复建设成本，而这需要实际部署数据来验证。

尽管如此，文章提出的层次区分对从业者有直接的使用价值：当 Agent 在长任务中出错时，先判断问题出在哪一层——是目标、进度和证据没有区分清楚（任务层），还是关键事实被压缩丢失或旧信息未被隔离（信息层），还是工具返回的成功不等于业务对象到达目标状态（动作层）。这个诊断框架不依赖于特定产品，而是对一类工程问题的结构化描述。