学习笔记：什么是 Agent Harness？

最近，我开始从系统架构的角度更深入地学习智能体（agent）。其中一个我觉得特别有用的理解框架是：

智能体 = 模型 + 支架

我曾经以为智能体的表现主要取决于模型的能力：更好的推理、更强的编程能力、更优的工具使用。但针对长时间运行的任务，论文指出，包围模型的支架系统同样至关重要。即使使用完全相同的模型，只要改进工具接口、上下文管理、执行环境、验证流程或任务编排，就能带来显著的性能提升。

这让我意识到 “智能体基础设施”并非单一狭窄的领域，它更像是将模型调用转化为可靠任务执行的完整系统栈。

论文提出了一个名为 ETCLOVG 的分类法来分解这套基础设施：

• 执行（Execution）： 智能体的运行环境。
• 工具（Tooling）： 智能体发现和调用工具的方式。
• 上下文（Context）： 模型能够看到的信息。
• 生命周期（Lifecycle）： 任务随时间演进的管理方式。
• 可观测性（Observability）： 追踪、成本、延迟和失败的监控。
• 验证（Verification）： 我们如何评估智能体是否真正成功。
• 治理（Governance）： 权限、策略和安全边界的实施。

案例研究：一个编码智能体

编码智能体是一个很好的例子。当我们说“智能体修复了一个 bug”时，并不是一次 LLM 调用就能神奇地生成补丁。一个完整的工作流程实际上更接近这样：

• ⚙️ 执行： 智能体在一个沙箱化的仓库环境中启动，以便它能检查文件、运行命令、执行测试，而不会触及用户的真实机器。
• 🛠️ 工具： 它使用搜索、grep、read_file、edit_file、run_tests 等工具与代码库交互。这些工具需要清晰的输入、结构化的输出和可靠的错误信息。
• 🧠 上下文： 它将相关文件、错误日志、问题描述以及之前的尝试带入上下文窗口，而不是加载整个仓库。
• 🔄 生命周期： 它遵循 编辑-测试-调试 的循环：理解 bug → 定位相关代码 → 提出修复方案 → 编辑文件 → 运行测试 → 检查失败 → 迭代。在真实系统中，这个生命周期可能复杂得多：重试、回滚、总结状态、从失败中恢复，或者将工作拆分到多个智能体。
• 📊 可观测性： 在过程中，系统记录追踪信息：打开了哪些文件、调用了哪些工具、消耗了多少 token、时间花在哪里、哪些环节失败了。
• ✅ 验证： 智能体通过运行测试或基准特定的检查来验证补丁，如果修复无效，则尝试归因失败原因。
• 🛡️ 治理： 系统强制执行边界：智能体能访问哪些文件、是否允许使用网络、在具有破坏性的命令前是否需要审批，以及如何审计操作。

这个框架帮助我连接了不少以前觉得分离的主题：

• RAG / 记忆 → 上下文
• MCP / 工具模式 → 工具
• SWE-bench / Terminal-Bench → 验证
• 沙箱化 → 执行
• 追踪分析 / 成本跟踪 → 可观测性
• 权限 / 审计 → 治理

我仍在思考的开放问题：

随着模型变得越来越强大，支架工程的影响会变小吗？还是说支架会变得更重要，因为更强的模型能够执行更多操作，从而需要更好的控制、验证和治理？

我目前的猜测是：某些支架技巧的相对影响会随时间减弱，但对一个健壮支架的需求很可能不会消失。

好奇大家怎么看 🤔

论文链接：https://picrew.github.io/LLM-Harness/