没有反馈基础设施，Agent 只是一个有权限的猜测者
TL;DR
Harness 编排 Agent 的行动，反馈基础设施提供判断依据；企业缺失的能力不会因为接入 AI 自动出现。
没有金刚钻，别让 Agent 揽瓷器活
“没有金刚钻，别揽瓷器活。”
这句话放到今天的 AI Agent 身上，再合适不过。
很多企业把 AI 当成突然得到的那枚“金刚钻”。模型越来越强，再接上知识库、内部系统，配上一套 Harness，过去积压的问题似乎就可以直接交给它：写代码、查故障、处理工单，甚至独立完成一段业务流程。
但当 Agent 真正开始行动，问题很快就会从“它能不能做”变成另外四个问题：
- 它是否知道自己刚才做了什么？
- 它如何判断结果是否符合目标？
- 它看到的变化，究竟是不是由自己的行动引起？
- 当证据不足时，它知道下一步应该做什么实验吗？
如果这些问题没有答案，Agent 即使能够调用再多工具，也只是在执行自己的猜测。区别无非是，以前它只能在对话框里猜，现在它可以带着权限进入真实系统，把猜测变成代码、配置和业务操作。
真正的“金刚钻”不是模型，而是企业过去积累的工程能力、数据治理、业务判断和问题排查方法。企业原本没有的能力，不会因为接入 AI 就突然出现。AI 反而会把那些过去由人勉强补上的缺口集中暴露出来。
这里讨论的不是回答问题或生成内容的一次性应用，而是那些已经获得工具和执行权限、开始对真实结果负责的 Agent。对于它们，能够行动只是起点。
Harness 让 Agent 能干活，却不能保证它干对了
上回那篇《Harness Engineering 又来颠覆了——你们开发不写文档、没有研发流程？》，我把 Harness Engineering 拆成了三条原则：可见性、状态持久化和质量门禁。
Harness 围绕这些原则组织上下文、工具、状态和执行循环，让 Agent 能够持续推进任务。但“能够持续工作”和“知道自己做对了”，并不是一回事。
Harness 可以在代码修改后运行测试，却不能替团队决定哪些测试足以证明修改正确；可以在部署后读取指标，却不知道延迟下降是否值得以更高的错误率为代价；可以调用评估器打分，却不能决定评分标准是否覆盖了真实风险。
这不是多做一次反思、再调用一个模型就能解决的问题。模型可以根据已有信息提出解释，却不能用自己的解释证明自己正确。Harness 可以安排失败后的重试，却不能凭空知道应该修改方案、换一种实验，还是承认证据不足并停下来。
Harness 编排 Agent 的行动，反馈基础设施承载组织的判断。
前者解决 Agent 怎样持续工作，后者解决它凭什么认为自己做对了。通用 Harness 可以接收和组织反馈，却不能替企业生产反馈。因为“什么算成功”“什么代价可以接受”“什么现象能够支持什么结论”，从来都不是 Agent 框架里的通用答案。
Agent 面对的，是四个一直存在的老问题
假设一个 Agent 接到任务：降低某个接口的响应延迟。它修改缓存策略并重新部署服务，监控显示延迟确实下降了，于是它宣布任务完成。这个过程看似完整，只要继续追问，结论就会变得不再确定。
可追踪：它是否知道自己做了什么
“修改了缓存策略”只是一句摘要。Agent 还需要知道改动了哪些配置和代码、部署到了哪个环境、当时有哪些变更同时发生，以及哪些请求开始走向不同的执行路径。
如果没有这些记录，几小时后错误率上升时，它无法完整还原现场。反馈首先要把一次行动与它影响的对象、版本、环境和时间连接起来。
可判定：它如何判断结果符合目标
响应延迟下降，并不等于优化成功。也许缓存命中率提高了，但用户读到了更旧的数据；也许平均延迟变好了，长尾延迟却明显恶化；也许成本被转移到另一个服务，只是没有出现在当前监控面板上。
“降低延迟”不能只是一个方向，还要说明在哪种负载下衡量、哪些正确性要求必须满足、哪些指标不能退化。目标需要成为一组包含约束和副作用检查的验收条件。
可归因：它看到的变化由什么引起
即使延迟下降，也不能立即证明缓存改动就是原因。部署期间可能刚好流量下降，上游服务可能同时扩容，数据分布也可能发生变化。时间上先后出现的两件事，并不自动构成因果关系。
工程师会固定输入重放请求、对比新旧版本、控制其他变量，或者只向一部分流量开放改动。监控告诉我们发生了变化，实验才能帮助我们判断变化为什么发生。
可修正：它知道下一步该验证什么吗
当结果与预期不符，最没有价值的动作就是原样重试。如果错误只出现在少数请求，下一步可能应该按输入特征分组；如果新旧版本只在高并发下出现差异，则应该改变测试负载，而不是继续修改算法。
每一步实验都应该排除一种解释，或者让一种假设获得更强的证据。好的反馈不只给出“成功”或“失败”，还要指出目前的不确定性，以及可以继续验证的方向。
这四个问题连起来，就是工程师一直在使用的问题解决流程：
观察异常 → 还原现场 → 提出假设 → 缩小范围
→ 设计实验 → 验证因果 → 判断结果 → 保留或回滚
AI Agent 没有改变这条路径。真正困难的从来不只是执行动作，而是为每一步行动找到足以支持下一步判断的证据。
过去不是没有反馈，只是反馈系统长在人的脑子里
凌晨两点，值班工程师收到一条错误率告警。他不会看到红灯就立刻回滚，而是先确认告警是否经常误报，再检查同一时段有没有发布，比较不同机房和请求类型的差异，最后决定是查数据库、下游依赖，还是找刚刚发布的团队确认。
监控系统提供了数据，但真正把告警、变更、系统结构和下一步行动连接起来的，是工程师经过长期实践形成的问题解决方法。
这种情况在企业里随处可见。大家知道某个指标的统计口径有问题，知道某个系统返回“成功”只代表请求已经受理，知道一条历史告警通常可以忽略，也知道某类异常虽然没有触发阈值，却值得立即升级。这些知识未必写在文档里，更没有被编码成规则，但资深人员会在工作中自然补上。
他们还承担着大量跨系统的人工连接：从监控平台看到异常，去发布系统查变更，到工单里确认影响范围，再从群聊中找到临时调整的背景。每个系统只提供一部分事实，最后由人拼成一条可以解释的因果链。
因此，一个团队能够完成目标、排查故障，不等于它已经拥有完整的反馈基础设施。很多时候，它只是拥有一批知道该看什么、该相信什么、接下来该做什么的人。
很多所谓的系统能力，其实一直寄存在少数人的脑子里。
一旦工作交给 Agent，这层人工补偿就不再自动生效。没有进入上下文的信息，对它来说并不存在；没有明确表达的判断标准，它只能根据已有模式生成一个看似合理的答案。人过去默默填上的缺口，都会变成反馈链路上的断点。
AI 没有制造这些问题，只是让组织清楚地看到：哪些能力已经沉淀在系统里，哪些仍依赖人的经验和关系，哪些从来没有真正建立过。
反馈基础设施，是把专家工作流变成系统能力
把专家工作流外化，不是安排资深工程师写一本更厚的操作手册。真正需要外化的，不只是他们最后给出的答案，而是获得答案的过程：依据什么信号发现异常，怎样区分事实与推测，用什么实验排除一种解释，又根据什么标准决定保留或放弃方案。
反馈基础设施也不一定是一套新平台。相关能力往往已经分散在现有系统中：测试平台保存正确性结果，发布系统记录变更，可观测性平台呈现运行状态，数据平台维护指标口径，灰度系统控制实验范围。
问题在于，它们没有围绕一次行动形成连续链路。Agent 完成了变更，却无法从告警追溯到这次变更；看到指标变化，却不知道统计口径刚刚调整；测试通过，却不知道测试只覆盖了正常路径。
反馈基础设施首先要做的，是让这些原本分散的事实可以相互解释。一次行动使用了什么输入、修改了什么对象、产生了哪些观察、通过了哪些验证、还有哪些风险未被覆盖，都应该沿着同一条链路被找到。
专家说“这个结果可以接受”，真正有价值的是这句话背后的条件。一次性能优化不能只要求平均延迟下降，还要说明使用什么负载测试，长尾延迟和错误率最多可以上升多少，结果一致性必须满足什么要求。这些条件被明确表达后，才会从临场判断变成 Agent 必须面对的验收契约。
这不意味着所有判断都要压缩成一个分数。好的反馈应该保留多个目标之间的冲突，也允许系统给出“当前证据不足”。如果评估器总能返回确定答案，它很可能只是把未知问题藏在了评分后面。
获取反馈的成本还必须足够低。能通过静态检查回答的问题，不必启动完整测试；能通过局部回放验证的假设，不必直接进入生产；只有局部收益得到验证、未发现不可接受的副作用后，才逐步扩大影响范围。验证越便宜、反馈越及时，Agent 就越有机会在影响范围尚小时修正方向。
并非所有专家经验都能立即变成规则。有些结果需要很久以后才能出现，有些异常只能结合具体语境判断，还有些后果不适合让 Agent 独立承担。系统必须明确区分：哪些结论可以自动验证，哪些只能得到概率性的信号，哪些必须升级给人。
反馈基础设施不是要消灭人的判断，而是把能够稳定复用的部分沉淀下来，再把剩余的不确定性准确地交还给人。
它所完成的，是一次组织能力的转化：把依赖个人经验的问题解决流程，转化为可重复、可调用、可验证，同时边界明确的系统能力。
可观测，不等于可判断
这套能力不能用数据量来衡量。日志、指标、调用链和评估分数可以让系统更加可观测，但这些信息不会自动变成反馈。
日志和指标回答“发生了什么”，却不能证明“为什么发生”。评估器可以检查格式、测试和阈值，却不能替企业决定阈值应该是多少，也无法发现没有写进标准的风险。把更多文档和历史记录放进上下文，同样不会自动消除过期信息与口径冲突。
一个客服 Agent 如果只按结单速度评分，最有效的策略可能是尽快关闭工单；一个编码 Agent 如果只按测试通过评分，最有效的策略也可能是绕过测试。评估器越稳定地执行错误标准，Agent 就越稳定地走向错误目标。
因此，评估器不是组织判断力的替代品，只是判断力中已经被明确表达、能够机械执行的那一部分。
好的反馈应该说明观察来自哪里、覆盖什么范围、能够支持什么判断、还不能证明什么，以及下一步可以通过什么方式继续验证。
好的反馈不是替 Agent 给出答案，而是用可靠证据约束它的下一步判断。
Agent 的自主上限，是组织存量能力的上限
反馈是否可靠，最终决定了企业能够把多少责任交给 Agent。讨论自主程度时，人们通常先想到权限：能不能修改代码、操作生产、直接回复客户，执行前是否需要人工审批。
但权限只决定 Agent 能把动作执行到哪里。真正限制自主权的，是错误能否被及时发现，原因能否被定位，影响范围能否被控制，结果能否被恢复。
一项任务如果有明确目标、稳定验证器和完整的副作用检查，Agent 就可以在边界内反复尝试。代码编译失败可以重来，测试未通过就不能合并，仿真结果不符合约束就放弃方案。错误不仅可见，还能在进入真实系统前被拦住。
验证无法消除所有错误，自主权还需要可恢复性。同一个错误，在沙盒里可能只是一次失败实验，在生产环境里却可能成为无法撤销的业务结果。能否授权 Agent 执行，不能只看它做对的概率，还要看做错后能否恢复。
“人在回路中”也不是万能答案。如果审批者看到的只有 Agent 的结论，没有行动记录、对照数据和风险范围，人工审批很容易变成形式确认。人只有获得足够证据，才能承担最后的判断。
Agent 的自主程度，不取决于企业愿意给它多少权限，而取决于企业能多快证明它错了，并把错误恢复掉。
企业能够稳定交给 Agent 的，只能是那些自己已经知道如何定义、观察、验证和恢复的工作。
模型能力越强，Agent 能够执行的任务越复杂，反馈基础设施的重要性反而越高。没有相应的可验证性和可恢复性，更多工具与更大权限只会扩大一次错误判断能够影响的范围。
真正的金刚钻
回到开头那句话。企业真正要做的，不是围绕 AI 重新发明问题解决方法，而是重新观察专家如何完成一项真实工作：他们依据什么判断任务完成，发现异常后先查看什么，如何验证因果，在什么情况下停止尝试，哪些操作必须可以撤销。
这些答案有多少已经进入系统，有多少仍然依赖口头传递和个人经验，就决定了 Agent 能接手多少工作。
模型能力会继续提高，Harness 也会逐渐标准化。每家企业都可以买到相近的模型，也能接入相似的工具。真正难以快速复制的，是一个组织多年积累的问题解决方法，以及把这些方法转化为数据、规则、实验和反馈链路的能力。
所谓“金刚钻”，从来不是突然出现的 AI，而是组织已经拥有，并且能够外化、传递和执行的问题解决能力。
企业原本没有的能力，不会因为接入 AI 就突然出现。没有反馈基础设施，给 Agent 再多数据、工具和权限，也只是让它更快、更大范围地猜测。
