Tag: Harness

1. 概述 1.1 为什么大模型越来越强，Agent 却仍然容易出问题 假设你希望 AI 帮忙排查一个线上问题：“最近五分钟，订单服务的错误率是否超过告警阈值？如果超过，请给出依据。” 一个普通聊天模型可能会告诉你，应该查看监控系统、统计错误请求、计算比例，再与阈值比较。回答看起来很合理，但实际工作还没有发生：监控数据没有被读取，计算没有真正执行，结论也没有对应证据。 给模型接上工具以后，情况有所改善。它可以请求查询指标，可以调用计算函数，也可以依据结果生成解释。但新的问题随之出现：查询参数写错怎么办？监控接口超时怎么办？模型连续调用同一个工具怎么办？模型把网页里的恶意文字当成指令怎么办？服务执行到一半重启怎么办？模型说“已完成”，系统就能直接向用户宣布成功吗？ 这些问题很少能靠“请认真思考”“不要犯错”“遇到错误自动重试”解决。因为提示词只是在影响模型产生什么输出，而这些问题涉及程序如何执行、权限如何判定、事实如何保存，以及失败后如何恢复。 一个真正可以长期工作的 Agent，需要模型之外的支撑系统。这个系统通常被称为 Agent Harness。中文没有完全统一的译法，可以理解为“智能体运行支架”或“智能体执行运行时”。本文保留 Harness 这个术语，因为它强调的是一组围绕模型组织起来的工程能力，而不是某一个特定的软件包。 先给出一个便于记忆的划分：模型提出行动，Harness 管理执行，环境返回事实，验证器判断结果。 这四个角色即使在代码里没有分别写成四个类，也应该在设计上保持清晰。 1.2 用一个项目团队理解 Harness 可以把大模型看成一位知识丰富、反应迅速的项目成员。他能够理解目标、制定方案、解释现象，但可能忘记前面的约束，也可能误判当前进度。 Harness 则类似于团队共同遵守的工作制度和配套设施：任务看板记录目标和进展；权限系统规定谁能修改什么；开发环境提供工具；日志系统保留操作记录；检查点让别人能够接手；验收标准决定任务是否完成。 这里的类比并不意味着模型真的拥有人的意图。它只是在帮助我们理解责任边界：再聪明的执行者，也需要可靠的工作环境；再完善的环境，也不能凭空补足执行者不具备的领域能力。 因此，Agent 的效果取决于多个因素共同作用：模型能力决定它能否理解问题和提出合适行动；上下文质量决定它是否看到了必要事实；工具质量决定它是否能准确影响环境；Harness 决定这些能力是否被稳定、可控地组织起来。…