引言：模型能力暴涨之后，系统的瓶颈究竟在哪里？
从 2022 年 GPT-3 时代迈入如今的强推理模型时代，一个现象变得越来越普遍：即便选用了最顶级的底层大模型，在处理复杂业务逻辑时，系统依然容易出现幻觉、死循环或步骤遗漏。
在红杉资本（Sequoia）举办的 Sovereign AI 讲座中，LangChain 联合创始人兼 CEO Harrison Chase 提出了一个非常核心的观察：当 Agent 在实际运行中出错时，大部分原因在于传入的上下文（Context）质量不过关，而不是底层模型的能力不足。
这就引出了当前 AI 智能系统构建的核心命题：我们该如何设计、评估并迭代 Agent 的运行框架（Harness）？本文将基于 Harrison Chase 的现场演讲，深度拆解 Agent 的三大构成要素、自研与外购 Harness 的边界判断、Harbor 沙盒评估标准，以及如何通过数据飞轮实现自动化的 Harness 工程升级。
一、解构 Agent 架构：Model、Context 与 Harness 的三角关系
要掌控一个 AI 系统，就必须明确系统的控制权究竟分布在何处。Harrison Chase 将 Agent 的工程体系拆解为三个不可分割的组成部分：
- Model（模型） ：负责基础推理、意图理解与工具调用的决策大脑。
- Context（上下文） ：在特定时间点输入给模型的全部信息，包括系统提示词（System Prompt）、历史对话、文件内容、工具执行结果及短期/长期记忆。
- Harness（运行框架） ：围绕模型建立的运行环境、循环逻辑与编排系统。
+-------------------------------------------------------------+
| Harness |
| +-------------------------------------------------------+ |
| | Context | |
| | +-------------------------------------------------+ | |
| | | Model | | |
| | +-------------------------------------------------+ | |
| +-------------------------------------------------------+ |
+-------------------------------------------------------------+Harrison 对 Harness 给出了一个工程化定义：Harness 的本质职责，就是在最合适的时间，将最精准的 Context 输送给 Model。
如果把 Model 比作引擎，那么 Context 就是注入引擎的燃料，而 Harness 则是输油管路、传动轴与整个控制系统。单纯升级引擎而不优化输油逻辑，系统必然频繁失速。
二、Harness 的演进：从基础工具循环到中间件扩展
最基础的 Agent 结构通常是一个简单的“模型调用工具”循环（Model-Tool Loop）：模型吐出工具指令 -> Harness 执行工具 -> 结果返回 Context -> 模型进行下一步推理。
但在实际落地中，这种基础循环很快就会遇到瓶颈，例如 Token 窗口爆满、死循环卡死、子任务无法并行等。LangChain 团队在构建 deepagents（一个对标 Claude Code 的通用 Agent 框架）时，给出了基于 Middleware（中间件）/ Hook 机制的解法。
通过在基础循环的外围增加钩子函数，开发者可以无侵入地挂载多种高级能力：
- 沙盒与文件系统隔离（Sandbox & Filesystem） ：限制 Agent 的本地读写权限，确保代码在安全隔离的容器内运行。
- 上下文卸载与总结（Context Offloading & Summarization） ：当对话历史接近上限时，自动触发总结中间件，压缩历史 Trace，保持 Context 处于精简状态。
- 子 Agent 调度（Sub-agents） ：主 Agent 将大任务拆解后，分发给特定领域的子 Agent 执行，子 Agent 拥有独立的 Harness 循环，完成后仅将总结结果吐回主 Context。
这种结构确保了底层的逻辑循环保持通用，而复杂业务规则可以通过层层中间件实现模块化叠加。
三、认知架构的选择：通用循环 vs 显式硬编码架构
在构建 Harness 时，团队往往面临认知架构的选型分歧：是采用高度自主的通用循环，还是硬编码的显式控制流？
1. 显式认知架构（Custom Cognitive Architectures）
在 2023 年至 2024 年初，由于底层模型自主规划能力较弱，业界广泛采用显式架构。例如 Deep Research 模式或 Code Review 机器人：
- 阶段一 ：强制进行并发搜索并扇出（Fan-out）多个子任务；
- 阶段二 ：针对每个搜索结果执行硬编码的评估步骤；
- 阶段三 ：汇总所有评估数据进入最终写作环节。
这种架构的优势在于可预测性高、执行路径明确。
在金融服务、法律合规等严监管行业，团队往往坚决拒绝高度自主的 Agent。正如某金融客户所言：“高度自主对我们来说太不可控了，我们必须采用显式认知架构，明确控制每一步的闸口（Gates）。”
2. 渐进式增加控制门控
Harrison Chase 给出的通用演进建议是：从通用 Harness 切入以最快速度验证价值（Time-to-Value），随着业务边界逐步清晰，再根据特定场景增加约束闸口。
不要一开始就硬编码复杂的流程图，也不要放任 Agent 无限制自主发挥，在通用循环中针对高风险节点加入人类确认（Human-in-the-loop）或代码校验门控，是平衡灵活度与稳定性的最佳实践。
四、Build vs Buy：自研还是使用现成 Harness？
当前市场上已经存在大量开箱即用的 Harness，例如 Claude Code、Codex 等。团队究竟该自研 Harness，还是直接使用现成方案？
Harrison Chase 提出了基于数据分布（Data Distribution）的决策模型：
[任务数据分布特性]
+-----------------+-----------------+
符合模型训练集 偏离模型训练集
(In-distribution) (Out-of-distribution)
【优先选购现成】 【必须自研 Harness】
如：通用 Coding、 如：特定行业法律审计、
通用 Write 企业私有 API 编排1. 内分布任务（In-distribution）
如果你的业务场景属于模型在预训练和微调阶段见过的大量通用数据（如标准 Python 编码、常规文档编写），现成的 Harness（如 Claude Code）已经针对这些场景做过深度优化。直接使用可以节省巨大的研发成本。
2. 超分布任务（Out-of-distribution）
如果你的业务涉及极其特殊的私有数据结构、复杂的内部系统 API、或是特定行业的业务流（如 Harvey 在法律领域的应用），现成 Harness 的效果会急剧下降。此时必须自研 Harness。
3. 微观工具适配细节（Model Profiles）
自研 Harness 并不意味着要重写所有细节。关键在于保留针对特定模型的微观最佳实践：
- OpenAI 模型 ：更倾向于通过特定 JSON Schema 的函数调用（Function Calling）来编辑文件；
- Anthropic 模型 ：在处理文本块替换（Str Replace）或特定 XML 标签描述的工具时表现更优。
一个成熟的自研 Harness 应当在底层维护不同模型的配置文件（Model Profiles），使自研的业务编排层能够无缝对接不同 Lab 模型的微观偏好。
五、基准评估（Evals）工程化：从跑分到 Harbor 开源标准化
微软 CEO Satya Nadella 曾提出著名的“逆向信息悖论”：在 AI 时代，模型能力正在趋同且日趋商品化，企业真正的核心资产在于私有评估基准（Private Evals）与决策轨迹数据（Traces）。
“必须建立你的私有 Evals，因为 Evals 定义了企业内部对‘优秀’的具体标准。掌握机构的内存、Trace、反馈与上下文，才能形成持续学习的闭环。”——Harrison Chase
1. Harbor 开源评估运行器
为了解决 Agent 在沙盒环境中评估困难的问题，由 Terminal Bench 2 团队开发的开源框架 Harbor 正在成为行业标准。
一个标准化 Harbor 评估任务包含四个核心文件：
Dockerfile：配置独立的沙盒运行环境；instruction.md：给 Agent 的自然语言任务指令；solve.sh：可选的基准解决方案脚本；test.sh：任务完成后的自动化断言与验证脚本。
通过 Harbor，企业可以在隔离容器中大规模并发运行 Agent，并通过 test.sh 输出客观的二元测试结果（Pass/Fail）。
2. 降低评估成本：小语言模型与纯代码判定
在全量 Trace 评估中，如果频繁调用顶级模型（LLM-as-a-judge）进行审查，会导致 Token 成本高昂。实践中推荐的三级评估梯队为：
- 第一级（代码断言） ：用 Python 脚本正则匹配、JSON 语法校验或 API 返回值直接判定；
- 第二级（小模型评估） ：使用经过特定任务微调的小语言模型（SLMs）审查输出逻辑；
- 第三级（大模型抽检） ：仅对高风险节点或复杂逻辑调用大模型进行抽样评判。
六、可观测性与 Trace 调试：Agent 报错背后的真正元凶
当 Agent 在第 8 轮交互中输出了错误代码，绝大多数开发者第一反应是“模型又出幻觉了”。但利用 LangSmith 查看完整轨迹（Trajectory）后，往往会发现真正的祸根埋在第 2 轮：
[第 1 轮] 用户提出需求
[第 2 轮] 工具返回了超长且包含不相关代码的文档 (上下文污染点)
[第 3-7 轮] 模型带着被污染的上下文继续推理
[第 8 轮] 模型输出错误答案 (结果呈现点)如果没有完整的 Trace 追踪系统，开发者只能看到第 8 轮的错误结果，进而盲目去修改 Prompt。真正有效的调试路径是：
- 收集完整 Trace ：记录每次调用的完整 Prompt、工具输入输出、耗时与 Token 开销；
- 定位首次偏离点 ：排查 Context 在哪一步引入了噪音或遗漏了关键信息；
- 优化 Context 供给 ：调整工具返回的数据格式或截断策略，而不是空改 Prompt。
七、持续改进的数据飞轮：从手动调试到 Agent 自动化 Harness 工程
传统的 Agent 迭代依赖工程师人工翻看日志、修改代码。Harrison Chase 在现场演示了基于 LangSmith Engine 的自动化 Harness 工程数据飞轮：
+-------------------------------------------------------+
v [ 1. 运行 Agent ]
v [ 2. 收集 Trace 轨迹 ]
v [ 3. 数据筛选与模式归纳 (隐式反馈/在线评估器) ]
v [ 4. 运行 Harbor 实验 (基准横向对比) ]
v [ 5. 更新 Agent 架构 (Harness 代码 / Prompt / 记忆) ]
+-------------------------------------------------------+自动化 Harness 工程演示（LangSmith Engine 实操）
在现场演示中，后台的 LangSmith Engine 自动扫描了真实运行中的 58,830 条 Trace：
- 步骤一（模式挖掘） ：Engine 自动从近 6 万条轨迹中整理出 36 个高频出现的系统性 Issue（如特定 API 格式解析失败、某些长文档被错误截断）；
- 步骤二（代码生成） ：针对特定 Issue，Engine 作为后台 Agent 自动定位到 Harness 的源代码文件；
- 步骤三（提交 Diff） ：Engine 直接生成代码修复补丁（Diff）与 Prompt 修改建议，并推送至 Slack 提醒工程师审查；
- 步骤四（Dogfooding 验证） ：LangChain 团队构建了针对 Engine 本身的基准测试
IssueBench，横向对比 Engine 与 Codex、Claude Code 在修复 Harness Bug 上的成功率。
这种“用 Agent 调试 Agent、用 Trace 生成代码补丁”的机制，意味着 Agent 系统的开发正在从“手动写代码”迈向“数据驱动的自动化工程迭代”。
八、总结与落地建议
构建高性能的 AI Agent 绝非简单地拼接 Prompt 与 API 调用。对于知识工作者与系统架构师而言，以下三条行动原则值得长期遵循：
- 明确系统控制权 ：始终清晰划分 Model、Context 与 Harness 的权责边界，优先通过优化 Context 供给来解决多数运行问题。
- 捍卫数据与 Eval 所有权 ：建立企业内部基于真实场景的私有评估基准（结合 Harbor 等标准框架），这是构建技术壁垒的唯一途径。
- 驱动数据飞轮运转 ：尽早搭建 Trace 采集系统，从手动查看日志逐步过渡到基于 Trace 数据自动归纳 Issue 与修复 Harness 代码。
把 AI 变成真正的生产力，关键不在于追求最新的模型参数，而在于构建一套具备自我演进能力的 Harness 体系。