AgentOps：用户快速地调教好你的Agent的关键功能。

AI资讯 5天前 charles

325 0 50

对于大部分 C 端场景，AI 回答得不好，人可以换个问法，或者不用这段答案，厂商基本不用承担法律责任。

但 B 端不行，如果你给客户推荐的供应商、商品出现了问题（如不符合其公司红线要求等），人家是可能找你麻烦的。

所以 AgentOps 对 B 端，或者 C 端某些重要场景（如交易场景），非常重要，这就要求我们给用户的 Agent 要可见、可溯源、可归因、可复盘等：

如果做不到这些，就直接给客户使用的话，那么就永远只能停留在助手的定位，不能真正成为客户的生产力。

举几个例子讲讲：

例子一：CI 修复 Agent 把测试修绿了，但把断言改松了

这个是对前面提到的 AI First 研发平台这类产品。

先看一个研发场景。

某个 PR 改了订单优惠计算逻辑，CI 里有一个单测失败。团队让 CI 修复 Agent 自动分析、修复，并开一个补丁 PR。它也正常执行了，且测试用例跑过。

第一眼看，Agent 很能干：

指标	结果
任务耗时	7 分 42 秒
模型调用	6 次
工具调用	11 次
修改文件	2 个
测试结果	订单模块单测通过
输出结果	自动开出修复 PR

如果记录的信息只有上面这些，只看这个表，会觉得不错，应该也是可以了。

但人工 Review 时发现，它不是修业务逻辑，也不是补测试数据，而是把测试断言从“必须等于 99.00”改成了“只要大于 0”。 -- 这个例子比较极端，但是比较好理解，就举这个了。

这就麻烦了：CI 绿了，质量却松了。

所以 AgentOps 不能只记录“成功”，它必须能把这次运行拆开。

一条最小可用的运行 trace，可能长这样：

时间	步骤	关键记录
10:12:03	接收任务	PR-4821，目标：修复 order-discount 单测失败
10:12:11	读取日志	失败用例：should_apply_coupon_after_member_discount
10:12:29	检索文件	读取 discount_calculator.go、discount_calculator_test.go
10:13:08	生成计划	判断失败原因：测试期望值与当前实现不一致
10:14:22	第一次修改	修改测试断言，放宽期望值
10:15:10	运行测试	go test ./order/... 通过
10:15:33	风险检查	未命中“断言放宽”规则
10:19:45	开 PR	输出：修复单测失败
10:36:18	人工 Review	驳回原因：断言被放松，没有证明业务逻辑正确

这个 trace 一出来，复盘就不再是“模型不靠谱”这种废话。

我们能看到几个具体问题：

第一，Agent 的目标写错了。

它的目标是“让测试通过”，而不是“在保持业务语义不变的前提下修复失败”。

第二，验证门太弱。

它只看测试是否通过，没有检查测试断言是否被放松。

第三，规则没进系统。

团队明明知道“不能为了修绿 CI 放松断言”，但这条规则只在老同事脑子里，没有进入 Agent 的检查清单(这个是假设的场景，常规下不会出现这类场景)。

这次复盘后，用户可以补三个动作：

CI 修复 Agent 的目标改成：优先修实现，其次修测试数据，禁止无证据放松断言。
增加一个静态检查：测试断言从精确值改成宽泛判断时，必须触发人工确认。
trace 里新增字段：changed_assertion_type，记录断言是否变弱。

这就是 AgentOps 的价值：不是多画一张 dashboard，而是让一次失败能变成下一次系统约束，持续优化团队的记忆、知识。

AgentOps 不是记录 Agent 干了什么，而是帮助团队判断它为什么这样干，成为团队持续进步的基石。

例子二：采购 Agent 推荐了高风险供应商，trace 发现是工具返回字段不够

再看一个 SaaS 的业务场景。

采购同学发起一个低值耗材寻源项目，希望采购 Agent 根据报价、历史履约和供应商资质等，给出推荐供应商。

采购 Agent 输出：“建议选择 A 供应商。该供应商本轮报价最低，历史交付及时率 96%，综合评分最高。”

第一眼看挺合理。

但人工复核时发现，A 供应商上个月刚因为质量异常被该品类临时冻结，按规则不能进入推荐名单。

这种错误很危险。采购侧不是写错一句话那么简单，它可能影响定标、合同、履约和供应链风险。后面真出了质量事故，没人会接受“这是模型没看到字段”的解释。

如果没有 AgentOps，复盘很容易变成互相甩锅：

模型为什么乱说？

知识库是不是过期？

采购规则是不是没写清楚？

工具是不是查漏了供应商状态？

但有 trace 后，问题会具体很多。

这次运行记录里，关键链路是这样的：

步骤	Agent 看到的内容	问题
意图识别	任务：为 MRO 低值耗材寻源项目推荐供应商	正确
寻源项目查询	项目金额：18 万；品类：办公耗材；候选供应商：A、B、C	正确
报价查询	A 供应商报价最低，低于第二名 4.8%	正确
供应商查询	A 供应商状态：合作中；历史交付及时率：96%；评分：92	少了“品类冻结”和“质量处罚”字段
采购规则检索	召回“低值耗材优先价格和交付稳定性”规则	没命中“冻结供应商不得推荐”规则
风险判断	风险等级：低	应为高风险
结果写回	写入“建议选择 A 供应商”	错误推荐被固化

这时候根因就清楚了。

不是单纯“模型太飘”，而是供应商查询工具返回字段不够。Agent 只看到了合作状态、报价和交付指标，没看到“该供应商在办公耗材品类下临时冻结”这个关键状态。

知识库也有问题：价格优先和交付稳定性规则排在前面，供应商冻结、质量处罚、品类准入这种硬规则没有被优先召回。

风险规则也有问题：只要供应商存在冻结、黑名单、资质过期、品类未准入，就应该强制拦截或转人工，而不是让 Agent 自己综合打分。

所以修复动作应该是三条线一起做：

供应商查询工具增加字段：品类准入状态、临时冻结状态、质量处罚、资质有效期、黑名单标记。
知识召回增加优先级：风险拦截规则高于价格、交付和评分规则。
风险规则写死：冻结 / 黑名单 / 资质过期 / 品类未准入 = 不得自动推荐，必须转人工复核。

修完以后，看板也要变化。

指标	修改前	修改后目标
高风险供应商拦截率	71%	98% 以上
错误推荐数	每周 2 起	连续 4 周为 0
供应商风险字段缺失导致失败	每周 4 起	每周复盘清零
高风险寻源项目人工接管率	22%	60% 以上

这里要注意一点：前期转人工率升高不一定是坏事。

在高风险采购场景里，转人工率升高，可能说明 Agent 学会了停下来总结、学习、提升。

所以管理者不能只看 Agent 的“自动化率越高越好”，否则很容易把 Agent 逼到错误推荐。

补一句：不少时候，一个团队的 Agent（买来的或者自己搞的）一开始运行的时候，不一定会带来团队的效率提升，尤其是业务很封闭、很复杂的场景下，需要有一个“学习、进化”的过程。

Agent 实现里，trace 要作为一等功能来做

两个核心点：

在 Agent Runtime 或 Harness 层，把Agent 每一步关键动作，都通过统一的运行单和事件流记录，而不是让每个 Agent 自己随手写日志（Harness团队不给力的时候就自己搞）。

为用户提供一个总结、提炼的入口与能力：SAAS的Agent不可能是自己玩的，得靠用户、客户积累。

下面是一些关键的落地点：

1. 任务运行单：先有 run_id，再开始干活

每次 Agent 开始执行前，先创建一张任务运行单。

字段	示例	作用
run_id	sourcing-agent-20260629-0008	串起一次完整运行
agent_id	supplier_recommend_agent	知道是谁干的
tenant_id	tenant_037	支持租户隔离和审计
task_type	supplier_recommendation	分场景统计
trigger_type	sourcing_project_submitted	人触发还是流程触发
input_object_id	sourcing_project_9042	回查业务对象
risk_level	medium	决定是否允许自动执行
owner	采购负责人 / 项目负责人	发生问题找得到责任人
status	running / blocked / completed / rejected	运行状态

这张运行单不是给平台装样子的。

后面的模型调用、上下文装配、工具调用、风险判断、验证结果、人工反馈，都要挂在这个 run_id 下面。

否则 trace 是散的，复盘时就会到处翻。

2. 上下文快照：记录“它当时看见了什么”

Agent 做错，很多时候不是推理能力问题，而是看错了世界。

所以 Context Builder 每次给 Agent 装配上下文时，要记录一份上下文快照。但注意，不一定要把所有原文都落库，尤其是 B 端场景里有客户数据、供应商资料、合同和价格。

至少要记录这些：

字段	示例
source_type	供应商主数据 / 采购规则 / 历史履约 / 质量异常
source_id	supplier_ A、rule_2026_08
source_version	v12、2026-06-20
permission_scope	当前用户可见 / 当前项目可见 / 脱敏后可见
retrieval_reason	因为任务品类是办公耗材，所以召回该品类准入规则
data_quality_flag	字段完整 / 字段缺失 / 版本可能过期
content_hash	用于证明当时读取的是哪一版内容

这一步非常关键。

比如前面采购 Agent 推荐错供应商，如果没有上下文快照，我们只能猜它有没有看到冻结状态。有了快照，就能确认：当时供应商查询结果里确实没有返回“品类冻结”字段。

这就能把问题从“模型乱推”定位到“Connector 字段缺失”。

3. 工具调用包装器：所有工具都要经过统一网关

所以工具调用不要让 Agent 直接散着调。建议统一走 Tool Gateway 或 Tool Wrapper。

每次工具调用记录这些：

字段	示例
tool_name	supplier_profile_query
tool_version	v3.4
request_schema_version	2026-06
params_summary	品类：办公耗材；候选供应商：A/B/C
params_hash	避免敏感参数明文扩散
permission_decision	allow / deny / require_approval
response_summary	A 供应商合作中，评分 92
missing_fields	category_freeze_status、quality_penalty
latency_ms	283
error_code	无 / 超时 / 权限不足 / 数据不完整

这里建议加两个字段：missing_fields 和 permission_decision。

很多 Agent 事故不是工具调用失败，而是工具“成功返回了不完整信息”。如果只记录 success，就会误导复盘。

4. 决策事件：记录它为什么选择这一步

Agent 不是传统程序，它中间会做很多判断。

比如：

是否推荐 A 供应商。

是否转人工。

是否开 PR。

是否放弃本轮修复。

这些关键判断要单独记成 decision_event，不能只埋在模型输出文本里。

字段	示例
decision_type	recommend_supplier
candidate_action	推荐 A 供应商
evidence_refs	报价最低、交付及时率 96%、评分 92
rule_hits	命中低值耗材价格优先规则
risk_rule_hits	未命中供应商冻结规则
confidence	0.78
alternative_actions	推荐 B；转人工；补充查询
why_not_human	系统判断为中低风险

这个字段设计得好，复盘会轻很多。

如果出错，就能看出是证据错了、规则没命中、风险等级错了，还是本来应该转人工却没转。

5. 验证事件：不要只记录“完成”，要记录“怎么证明完成”

Agent 说“我完成了”没意义。

关键是它靠什么证明自己完成。

研发 Agent 的验证可能是测试、lint、静态检查、人工 Review。

采购 Agent 的验证可能是供应商状态回查、黑名单校验、资质有效期校验、品类准入规则校验、审批状态确认。

所以要有 validation_event：

字段	示例
validation_type	供应商风险校验
check_name	黑名单 / 冻结 / 资质有效期 / 品类准入
check_result	pass / fail / skipped
evidence_ref	supplier_risk_query_0007
skipped_reason	工具未返回字段 / 权限不足 / 规则未配置
must_human_review	true / false

这里最怕的是 skipped_reason 没记录。

很多事故复盘时才发现，关键检查其实没跑，但系统仍然给了“完成”。

6. 人工反馈回写：Review 结果必须回到 trace 和 eval

Agent 被人工驳回，不应该只停留在审批页面里。

比如采购负责人驳回了 A 供应商推荐，理由是“供应商处于该品类冻结期”。这个反馈至少要写回三处：

写回 run_id 对应的 trace，作为本次运行结果。
写回失败案例库，归因为工具字段缺失 / 风险规则未命中。
写回 eval 样本，下次模型、工具、规则变更时必须回归。

如果人工反馈不回流，团队就会反复踩同一个坑。

AgentOps 不是把运行记录存起来，而是让运行记录能反向训练系统。

一个最小可用的 Agent 运行记录示例

结合上面两个例子和实现拆解，要做一个合理规划版本，每个 Agent task 都可以记录这些字段。

字段	例子	用途
run_id	ci-fix-20260628-0017	串起一次完整运行
task_type	CI 修复、供应商推荐、发布说明	分场景统计
trigger	CI 失败、寻源项目提交、release 创建	看触发来源
risk_level	低 / 中 / 高	决定是否自动执行
input_object	PR-4821、寻源项目-9042、发布单-126	回查业务对象
context_sources	日志、供应商资质、采购规则版本、发布记录	判断是否看错事实
plan_steps	读取日志、检索代码、修改文件、跑测试	回放行动路径
tool_calls	调用供应商查询、寻源比价、测试命令、发布系统查询	追踪工具和权限
decision_points	是否转人工、是否开 PR、是否拦截推荐、是否发布草稿	复盘关键判断
validation	测试通过、规则命中、人工确认	判断结果是否可信
cost	token、耗时、模型调用次数	控制成本
outcome	成功、人工驳回、用户投诉、测试失败	进入看板
follow_up	改 prompt、补工具字段、加 eval case	进入改进闭环

这些字段不一定一开始全做完。

但如果连 run_id、上下文来源、工具调用、关键判断、验证结果、人工反馈都没有，就很难谈 AgentOps。

因为出了问题以后，你不知道从哪里改。

用户侧周复盘：把 Agent 用成自己的业务学习系统

与普通软件产品ops用户是产品的运维、运营人员，AgentOps的用户有很大一部分应该是终端用户。

有了 trace、运行单、上下文快照、工具调用和人工反馈之后，SaaS 产品（自用产品也一样）要给用户一个可视化、可接入的入口，让用户能看见 Agent 的行为，评估它的判断，最后决定哪些东西要沉淀到知识和记忆里。

以采购部负责人的视角为例，他不关心底层有多少日志。他更关心这张表：

复盘项	本周看到的问题	用户侧改进
自动完成	低风险耗材推荐基本稳定	继续放开低风险品类
人工驳回	A 供应商因品类冻结被驳回	补充冻结规则和供应商状态字段
规则问题	老采购知道的红线系统不知道	把红线写成规则和审批条件
使用问题	有人把 Agent 建议当最终结论	明确“建议、审批、执行”的责任边界