## TL;DR

Harness 编排 Agent 的行动，反馈基础设施提供判断依据；企业缺失的能力不会因为接入 AI 自动出现。

## 没有金刚钻，别让 Agent 揽瓷器活

“没有金刚钻，别揽瓷器活。”

这句话放到今天的 AI Agent 身上，再合适不过。

很多企业把 AI 当成突然得到的那枚“金刚钻”。模型越来越强，再接上知识库、内部系统，配上一套 Harness，过去积压的问题似乎就可以直接交给它：写代码、查故障、处理工单，甚至独立完成一段业务流程。

但当 Agent 真正开始行动，问题很快就会从“它能不能做”变成另外四个问题：

1. 它是否知道自己刚才做了什么？
2. 它如何判断结果是否符合目标？
3. 它看到的变化，究竟是不是由自己的行动引起？
4. 当证据不足时，它知道下一步应该做什么实验吗？

如果这些问题没有答案，Agent 即使能够调用再多工具，也只是在执行自己的猜测。区别无非是，以前它只能在对话框里猜，现在它可以带着权限进入真实系统，把猜测变成代码、配置和业务操作。

真正的“金刚钻”不是模型，而是企业过去积累的工程能力、数据治理、业务判断和问题排查方法。企业原本没有的能力，不会因为接入 AI 就突然出现。AI 反而会把那些过去由人勉强补上的缺口集中暴露出来。

这里讨论的不是回答问题或生成内容的一次性应用，而是那些已经获得工具和执行权限、开始对真实结果负责的 Agent。对于它们，能够行动只是起点。

## Harness 让 Agent 能干活，却不能保证它干对了

上回那篇《[Harness Engineering 又来颠覆了——你们开发不写文档、没有研发流程？](https://atbug.com/harness-engineering-sdlc/)》，我把 Harness Engineering 拆成了三条原则：可见性、状态持久化和质量门禁。

Harness 围绕这些原则组织上下文、工具、状态和执行循环，让 Agent 能够持续推进任务。但“能够持续工作”和“知道自己做对了”，并不是一回事。

Harness 可以在代码修改后运行测试，却不能替团队决定哪些测试足以证明修改正确；可以在部署后读取指标，却不知道延迟下降是否值得以更高的错误率为代价；可以调用评估器打分，却不能决定评分标准是否覆盖了真实风险。

这不是多做一次反思、再调用一个模型就能解决的问题。模型可以根据已有信息提出解释，却不能用自己的解释证明自己正确。Harness 可以安排失败后的重试，却不能凭空知道应该修改方案、换一种实验，还是承认证据不足并停下来。

> **Harness 编排 Agent 的行动，反馈基础设施承载组织的判断。**

前者解决 Agent 怎样持续工作，后者解决它凭什么认为自己做对了。通用 Harness 可以接收和组织反馈，却不能替企业生产反馈。因为“什么算成功”“什么代价可以接受”“什么现象能够支持什么结论”，从来都不是 Agent 框架里的通用答案。

## Agent 面对的，是四个一直存在的老问题

假设一个 Agent 接到任务：降低某个接口的响应延迟。它修改缓存策略并重新部署服务，监控显示延迟确实下降了，于是它宣布任务完成。这个过程看似完整，只要继续追问，结论就会变得不再确定。

### 可追踪：它是否知道自己做了什么

“修改了缓存策略”只是一句摘要。Agent 还需要知道改动了哪些配置和代码、部署到了哪个环境、当时有哪些变更同时发生，以及哪些请求开始走向不同的执行路径。

如果没有这些记录，几小时后错误率上升时，它无法完整还原现场。反馈首先要把一次行动与它影响的对象、版本、环境和时间连接起来。

### 可判定：它如何判断结果符合目标

响应延迟下降，并不等于优化成功。也许缓存命中率提高了，但用户读到了更旧的数据；也许平均延迟变好了，长尾延迟却明显恶化；也许成本被转移到另一个服务，只是没有出现在当前监控面板上。

“降低延迟”不能只是一个方向，还要说明在哪种负载下衡量、哪些正确性要求必须满足、哪些指标不能退化。目标需要成为一组包含约束和副作用检查的验收条件。

### 可归因：它看到的变化由什么引起

即使延迟下降，也不能立即证明缓存改动就是原因。部署期间可能刚好流量下降，上游服务可能同时扩容，数据分布也可能发生变化。时间上先后出现的两件事，并不自动构成因果关系。

工程师会固定输入重放请求、对比新旧版本、控制其他变量，或者只向一部分流量开放改动。监控告诉我们发生了变化，实验才能帮助我们判断变化为什么发生。

### 可修正：它知道下一步该验证什么吗

当结果与预期不符，最没有价值的动作就是原样重试。如果错误只出现在少数请求，下一步可能应该按输入特征分组；如果新旧版本只在高并发下出现差异，则应该改变测试负载，而不是继续修改算法。

每一步实验都应该排除一种解释，或者让一种假设获得更强的证据。好的反馈不只给出“成功”或“失败”，还要指出目前的不确定性，以及可以继续验证的方向。

这四个问题连起来，就是工程师一直在使用的问题解决流程：

```text
观察异常 → 还原现场 → 提出假设 → 缩小范围
→ 设计实验 → 验证因果 → 判断结果 → 保留或回滚
```

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 再多数据、工具和权限，也只是让它更快、更大范围地猜测。

Harness 编排 Agent 的行动，反馈基础设施提供判断依据；企业缺失的能力不会因为接入 AI 自动出现。

没有反馈基础设施，Agent 只是一个有权限的猜测者

人工智能

架构设计

运维

Harness编排Agent行动，反馈基础设施提供判断依据；企业缺失的能力不会因接入AI自动出现。可追踪、可判定、可归因、可修正四维反馈链路决定Agent自主上限，真正金刚钻是组织沉淀的问题解决能力。

数据治理

负载测试

代码解释

数据库

Agent

让每一个 Agent，都跑在云上

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

没有反馈基础设施，Agent 只是一个有权限的猜测者-腾讯云开发者社区-腾讯云

没有反馈基础设施，Agent 只是一个有权限的猜测者

没有反馈基础设施，Agent 只是一个有权限的猜测者

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐