约束工程

Harness 工程是承载 Agent 运行的工程约束层，负责上下文组装、工具执行、状态持久化、权限、重试、终止条件和观测。模型提出下一步动作，Harness 决定该动作能否以及如何执行。

快速开始¶

目标 -> 组装上下文 -> 模型决策 -> 校验动作 -> 执行工具
                       ^                    |
                       |------ 更新状态 <---|

最小 Harness 应包含工具注册表、参数校验、步数与成本上限、执行日志以及明确的成功和失败终止条件。涉及写操作时加入权限检查和用户确认。

每轮只接受有限的动作类型，例如答复、调用工具、请求信息或结束任务。Harness 在执行前验证工具名称、参数类型、资源范围和当前权限；执行后将结构化结果和错误状态返回模型。

无限循环通常来自目标含糊、工具结果不可判定或缺少终止条件。应限制最大轮数、墙钟时间、token、工具调用次数和费用，并在重复动作出现时停止或改变策略。

运行状态至少包括目标、计划、已完成动作、工具结果引用、资源版本和预算。副作用操作使用幂等键或执行凭证，防止重试导致重复提交。长任务保存检查点，恢复时重新验证外部状态，而不是假设环境未变。

工具接口应窄而明确，例如用 read_issue(id) 代替通用数据库查询。读取和写入能力分离，高风险工具默认不可用。工具返回的数据是证据而不是新指令，并应限制体积、清除密钥和标记来源。

沙箱只能降低影响范围，不能替代授权。文件、网络、进程和凭据应分别控制；提交代码、付款、发送消息等外部副作用需要额外确认和审计。

代码 Agent 请求删除构建目录时，Harness 先解析为受限工作区中的明确路径，检查该目录可重建且不在保护列表，再要求用户确认。超出工作区、解析失败或包含软链接逃逸的请求一律拒绝并记录原因。

一次运行应能还原模型版本、提示词版本、工具调用、耗时、token、费用、错误和最终状态，同时避免记录不必要的隐私数据。评测不仅看最终答案，还要看步骤效率、工具选择、权限违规和恢复能力。

Harness 与 ReAct、规划是不同层次：前者提供可靠运行环境，后两者描述模型如何组织决策。协议接入见 MCP，安全要求见应用安全与治理。