Harness 不是外壳，而是 Agent 的工作环境
LangChain 这篇文章把一句话讲得很清楚，Agent 可以理解成 model 加 harness。模型负责推理，Harness 负责把模型接到真实世界，提供上下文、工具、环境、策略和状态。很多 Agent 不好用，不是模型不行，而是 Harness 没有给到正确上下文，或者把工具、业务规则和安全策略全部塞进 prompt 里。
先从最小 Harness 开始
LangChain 的 `create_agent` 是一个很小的起点，给它模型、工具和系统提示，就能跑一个基础 agent loop。实战里不要一上来堆复杂中间件。先选一个任务，把模型需要知道的上下文、允许调用的工具、最终输出格式和失败边界写清楚。这个最小版本能稳定跑，再加 memory、sandbox、approval、eval 和动态模型选择。
Middleware 是定制重点
文章里最值得带走的是 middleware 思路。它可以在模型调用前后、工具调用前后、启动和结束时介入。确定性业务逻辑、策略执行、工具注册、上下文压缩、模型切换、日志采集和资源清理，都应该放在 middleware，而不是写进一段越来越长的系统提示。这样 Harness 才可测试、可替换、可观测。
适合放进 Middleware 的东西
- 任务复杂度判断，简单任务用便宜模型，复杂任务切强模型。
- 工具白名单，根据用户权限和任务类型动态暴露工具。
- 敏感操作拦截，例如删除文件、发送邮件、部署、写数据库。
- 上下文整理，把长历史压缩成当前任务需要的事实。
- 运行结束清理，关闭连接、删除临时文件、归档日志。
不要把 Harness 做成黑箱
Harness 越强，越需要透明。每次模型调用拿到了什么上下文，哪些工具被注册，哪个 middleware 拦截了动作，最终为什么停止，都要能看。否则团队会把所有问题都归咎于模型，但真正的 bug 可能在工具初始化、上下文注入或权限判断里。
一条工程化路线
可以先用 `create_agent` 做最小可用版本，再把重复出现的 prompt 规则下沉到 middleware，把高风险工具接入审批，把长任务接入 trace，把输出接入 rubric 或测试。每加一层，都要有对应的日志和单元测试。Agent Harness 的成熟度，不看它支持多少工具，而看失败时能不能说清发生了什么。
建议产出
读完这篇文章后，建议画一张自己的 Agent Harness 分层图，至少包含模型层、上下文层、工具层、middleware 层、审批层、观测层和输出验证层。以后新增 Agent，不要从 prompt 开始，而是先决定它需要哪一套 Harness。