Agent三要素：Harness、模型与上下文
我越来越觉得，企业谈“掌控自己的 AI”，不能只盯着模型。
一个 Agent 至少有三个相互制约的部分：模型负责推理，Harness 负责编排，上下文提供完成任务所需的信息。任何一部分失控，系统都很难稳定。
模型当然重要，但真正拉开企业应用差距的，往往是后两者。
Harness 是上下文调度系统
Harness 的核心任务，可以压缩成一句话：在正确的时间，把正确的上下文交给模型。
这里既有固定信息，也有运行中不断产生的动态信息。Agent 调用工具、访问文件、连接外部系统，每一步都会生成新的结果，再被送回模型，进入下一轮判断。
因此，Agent 的基础架构并不神秘：一个模型在循环中调用工具，根据工具返回的结果继续行动。Harness 就是这个循环的中枢，决定哪些信息进入、何时进入、如何处理，以及下一步往哪里走。
看起来相似的 Agent，能力差异常常不在这个基础循环，而在循环周围的控制方式。
大部分定制不必推倒重来
定制 Harness，通常可以从钩子、中间件和插件开始。
在模型调用前，可以检查上下文是否过长并自动摘要；在工具返回后，可以把大体量结果转储，只保留索引或关键信息；在关键节点，可以接入沙盒、文件系统、记忆、技能或子 Agent。
这些机制都没有改变 Agent 的基本结构，只是在核心循环的不同位置加入控制逻辑。
对于高度专业的任务，还可以增加更明确的认知架构。例如，研究任务先拆分子问题，代码审查按照固定步骤逐项检查。这类流程能够约束模型，但也会增加系统复杂度。
我的判断是，开始时应尽量使用通用 Harness，先让系统跑起来。等真实用例暴露出稳定的问题，再增加门控、检查和专用流程。过早设计复杂架构，往往是在没有数据时猜测问题。
自建的边界是任务分布
是否自建 Harness，关键不是企业有没有技术团队，而是任务与模型既有能力的距离。
任务越接近模型训练和强化学习覆盖的分布，现成 Harness 通常越有效。任务越偏离这个分布，越需要围绕业务流程做定制。
但不能只看宏观任务。一个法律 Agent 的整体工作可能很专业，其中“编辑文件”这样的子任务，却可能正处于主流模型擅长的分布内。
这意味着，宏观流程可以定制，底层能力却应尽量顺着模型原有的工作方式。不同模型在各自 Harness 中接受过不同的工具训练，强行用一套抽象抹平差异，未必能得到最好的结果。
企业需要的是模型可切换能力，而不是假装所有模型完全一样。避免供应商锁定很重要，但切换模型时，也要同步适配与它匹配的工具和上下文组织方式。
Agent 出错，先检查上下文
Harrison Chase 把 Agent 故障归为两类：模型能力不足，或者模型收到的上下文质量太差。他认为，绝大多数问题属于后者。
这个判断很重要。很多团队发现结果不理想，第一反应是换更大的模型。可如果送入模型的信息缺失、冲突、过期，或者在多轮调用中被错误压缩，再强的模型也只能在坏上下文上推理。
所以，可观察性不能只记录最终答案。真正有用的调试信息包括：什么内容进入了上下文窗口，上下文怎样累积，Agent 调用了哪些工具，每一步返回了什么，以及信息如何在整个流程中流转。
轨迹适合快速浏览，完整追踪则用于深入定位。两者都需要：前者让人看懂，后者让人查清。
私有评估定义企业自己的优秀
通用排行榜只能说明模型的平均能力，不能替企业定义什么叫“做得好”。
只要 Agent 承担关键任务，企业就应该建立自己的评估集。它既用于比较不同模型、Harness 和推理策略，也用于发现版本回归。
评估不能只看准确率。延迟、Token 消耗和运行成本同样是产品指标。一个答案更好但响应慢得无法使用的 Agent，并不是真正更好的系统。
原文介绍的 Harbor，把任务、独立运行环境、参考解决方案、验证脚本和指令打包，在沙盒中并行运行，再对不同组合进行评分。具体工具可以变化，方法本身更值得保留：把真实任务变成可重复、可验证、可比较的实验。
反馈要进入数据飞轮
评估和可观察性的最终价值，不是生成一张报表，而是形成持续改进的闭环。
这个闭环包括：构建 Agent，投入运行，收集追踪，筛选数据，运行实验，再根据结果更新 Harness、模型或上下文。
其中最容易被忽视的是反馈设计。用户未必会主动点击赞或踩，但修改、撤销、重试、人工接管等行为，本身就是隐式反馈。界面如何呈现 Agent 的工作过程，会直接影响企业能否获得高质量数据。
反馈也可以自动生成。简单问题可以用代码规则判断，复杂问题可以让模型评审。没有必要让最昂贵的模型检查每一条记录，应根据任务难度选择成本合适的评估方式。
LangSmith Engine 展示的方向，是让后台 Agent 从追踪记录中发现共性问题，生成问题清单，并尝试修改提示词、上下文和 Harness 代码。它说明数据飞轮还可以进一步自动化，但自动生成修复方案并不等于可以跳过验证。
企业真正要积累的是系统能力
模型会持续升级，也可以被替换。企业更持久的资产，是自己的任务数据、上下文体系、运行追踪、评估标准和改进机制。
Harness、模型与上下文构成了 Agent，评估与可观察性则把三者连成一个能够学习的系统。
架构可以很简单。真正困难的，是看清系统内部发生了什么，并把每一次运行留下的数据，转化为下一次改进的依据。