单次 Demo 能跑，不代表 Agent 可以交给真实用户。模型输出、工具调用、状态恢复、权限控制和人工介入之间，还需要一个稳定的运行外壳，这就是我理解的 Harness Engineering。

Harness 管的是整个运行环境

它通常包括明确的项目指令、上下文策略、工具契约、状态机、结构化输出、权限、超时重试、日志追踪和评估回归。模型提供灵活判断，Harness 把这种判断限制在可测试、可恢复的轨道里。

请求 -> 身份与策略 -> 上下文构建 -> Agent 循环 -> 工具治理 -> 产物校验 -> Trace/指标

六类能力缺一不可

任务规范让 Agent 知道目标；工具层提供受控行动；状态层支持暂停恢复；验证层检查结果；可观测层解释过程；安全层限制权限和副作用。不同项目可以用不同框架，但这些工程问题不会因为换模型自动消失。

AGENTS.md 一类文件为什么重要

仓库级说明可以把项目结构、常用命令、禁止操作、编码约定、验证步骤和交付格式版本化。它不是越长越好，而应把最容易被误解、最影响结果的约束写清楚。能由测试、lint 或权限系统强制的规则，仍然应该落到代码，不要只写在说明里。

结构化输出是重要支点

当下游需要 JSON 时，应该使用 schema 约束、解析验证和修复/重试策略，而不是从一段 Markdown 中正则提取。高风险动作还要加入审批节点与幂等机制。Harness 的价值正是把这些“每次都要小心”的事情变成系统默认。

这章给我的启发

模型决定 Agent 能想到什么，Harness 决定它能否稳定地做对。把提示、工具、状态、验证和追踪放在一起看，才真正从模型调用走向了 Agent 工程。

文章摘自：https://www.cnblogs.com/hazy-star/p/22690948