大语言模型

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

2026 年 6 月 30 日

快速调教好Agent的关键在于实现可观测与可追溯，让AI真正成为生产力工具而非隐患。核心内容： 1. B端场景下AgentOps的刚需与核心要求 2. 通过CI修复Agent的极端案例揭示问题本质 3. 一条最小可用的运行trace所揭示的具体改进点

对于大部分 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 建议当最终结论	明确“建议、审批、执行”的责任边界

比如 A 供应商因为品类冻结被驳回，这件事不应该只停留在“Agent 又错了”。采购负责人应该能在工作台里直接标记原因，并决定：把“品类冻结供应商不得推荐”沉淀为采购知识，把“办公耗材推荐前先查冻结和质量处罚”沉淀为团队记忆。

这时候 AgentOps 就不只是可观测性，而是用户自己的改进入口。

它让采购团队看清楚：哪些是 Agent 的问题，哪些是主数据的问题，哪些是规则没有沉淀，哪些只是一次临时失败，应该留在 trace 里。

好的 trace 像一束光，照见 Agent 的路径，也照见业务系统里那些平时被灰尘盖住的角落。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

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

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单