Anthropic 最近发布了一篇关于 Harness 的工程实践。表面看是在讲产品实现，实质上回答的是一个更长期的问题：
当模型能力持续变化时，Agent 系统哪些层要稳定，哪些层应该允许快速替换？
我对这篇文章的核心理解是：Agent 基础设施会越来越像一个轻量的 Agent OS。
重点不在“把今天的**流程写死”，而在“定义长期稳定的系统抽象”。
很多 Agent 框架常见的问题是：
- 把模型的临时短板固化为永久架构
- 把 prompt 工程误当成系统边界
- 把一次有效的补丁写成长期依赖
模型会变强，今天合理的补丁，明天可能就是技术债。
这套思路不是承诺某一种固定编排方式，而是抽象出三层稳定接口：
session：可恢复的事件与状态历史harness：推理与调度循环（brain）sandbox：执行环境与工具能力（hands）
它们分离后，系统更容易替换、恢复和扩展。
一个关键观点是：Session 不等于模型上下文。
Session 应该是可查询、可回放、可恢复的事件日志，而不是直接塞给模型的历史拼接。
这样做的价值：
- trimming 不等于历史消失
- compaction 不等于事实丢失
- 崩溃恢复可以回到事件层，而不是依赖摘要记忆
Harness 应专注于调度，而不是持有业务状态。
理想接口更接近：
execute(name, input) -> string
这意味着模型只关心“我能调用什么能力”，而不强绑定具体设备、容器或操作系统。
当 brain 和 hands 解耦：
- 工具环境可以独立演进
- 不同基础设施可以并行接入
- 不必每个会话都预热完整执行环境
这直接带来更好的启动与扩展表现。
这种拆分通常会同时改善性能和安全。
性能上：
- 可以先启动 brain，再按需拉起 hands
- 降低首 token 延迟（TTFT）
安全上：
- 不把高敏凭证直接暴露给模型
- 用受控 proxy / vault 做间接凭证访问
- 安全边界建立在系统约束上，而不是“模型应该做不到”
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/255553.html