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

# 快速调教好Agent的关键：可观测与可追溯，让AI真正成为生产力工具而非隐患 先说说背景。对于大部分C端场景，AI回答得不好，用户可以换个问法，或者干脆不用这段答案，厂商基本不用承担什么法律责任。但B端完全是另一回事——如果你给客户推荐的供应商、商品出现了问题（比如不符合公司红线要求），人家是真的可能找你麻烦的。 所以AgentOps对B端场景，或者C端某些重要场景（比如交易场景），就显得格外重要。核心要求其实很简单：可见、可溯源、可归因、可复盘，这几样缺一不可。如果做不到这些就直接扔给客户用，那这个Agent永远只能停留在“助手”的定位，永远成不了真正的生产力工具。 下面用两个具体例子来说明。 **01 例子一：CI修复Agent把测试修绿了，但把断言改松了** 这个场景针对的是AI First研发平台这类产品。先看一个研发场景：某个PR改了订单优惠计算逻辑，CI里有一个单测失败了。团队让CI修复Agent自动分析、修复，然后开一个补丁PR。Agent正常执行了，测试用例也跑过了。 第一眼看，Agent的表现似乎不错： | 指标 | 结果 | |------|------| | 任务耗时 | 7分42秒 | | 模型调用 | 6次 | | 工具调用 | 11次 | | 修改文件 | 2个 | | 测试结果 | 订单模块单测通过 | | 输出结果 | 自动开出修复PR | 如果记录的信息只有上面这些，只看这个表，你会觉得挺好，应该可以了。但人工Review时发现问题了——Agent不是修业务逻辑，也不是补测试数据，而是把测试断言从“必须等于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的检查清单。 这次复盘后，用户可以补三个动作： 1. CI修复Agent的目标改成：优先修实现，其次修测试数据，禁止无证据放松断言。 2. 增加一个静态检查：测试断言从精确值改成宽泛判断时，必须触发人工确认。 3. trace里新增字段：changed_assertion_type，记录断言是否变弱。 这就是AgentOps的价值——不是多画一张dashboard，而是让一次失败能变成下一次系统约束，持续优化团队的记忆和知识。 **02 例子二：采购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自己综合打分。 所以修复动作应该是三条线一起做： 1. 供应商查询工具增加字段：品类准入状态、临时冻结状态、质量处罚、资质有效期、黑名单标记。 2. 知识召回增加优先级：风险拦截规则高于价格、交付和评分规则。 3. 风险规则写死：冻结/黑名单/资质过期/品类未准入=不得自动推荐，必须转人工复核。 修完以后，看板也要变化： | 指标 | 修改前 | 修改后目标 | |------|--------|------------| | 高风险供应商拦截率 | 71% | 98%以上 | | 错误推荐数 | 每周2起 | 连续4周为0 | | 供应商风险字段缺失导致失败 | 每周4起 | 每周复盘清零 | | 高风险寻源项目人工接管率 | 22% | 60%以上 | 这里要注意一点：前期转人工率升高不一定是坏事。在高风险采购场景里，转人工率升高，可能说明Agent学会了停下来总结、学习、提升。所以管理者不能只看Agent的“自动化率越高越好”，否则很容易把Agent逼到错误推荐。 补一句：不少时候，一个团队的Agent（买来的或者自己搞的）一开始运行的时候，不一定会带来团队的效率提升，尤其是业务很封闭、很复杂的场景下，需要有一个“学习、进化”的过程。 **03 Agent实现里，trace要作为一等功能来做** 两个核心点： - 在Agent Runtime或Harness层，把Agent每一步关键动作，都通过统一的运行单和事件流记录，而不是让每个Agent自己随手写日志。 - 为用户提供一个总结、提炼的入口与能力：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供应商推荐，理由是“供应商处于该品类冻结期”。这个反馈至少要写回三处： 1. 写回run_id对应的trace，作为本次运行结果。 2. 写回失败案例库，归因为工具字段缺失/风险规则未命中。 3. 写回eval样本，下次模型、工具、规则变更时必须回归。 如果人工反馈不回流，团队就会反复踩同一个坑。AgentOps不是把运行记录存起来，而是让运行记录能反向训练系统。 **04 一个最小可用的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。因为出了问题以后，你不知道从哪里改。 **05 用户侧周复盘：把Agent用成自己的业务学习系统** 与普通软件产品ops用户是产品的运维、运营人员不同，AgentOps的用户有很大一部分应该是终端用户。 有了trace、运行单、上下文快照、工具调用和人工反馈之后，SaaS产品（自用产品也一样）要给用户一个可视化、可接入的入口，让用户能看见Agent的行为，评估它的判断，最后决定哪些东西要沉淀到知识和记忆里。 以采购部负责人的视角为例，他不关心底层有多少日志。他更关心这张表： | 复盘项 | 本周看到的问题 | 用户侧改进 | |--------|----------------|------------| | 自动完成 | 低风险耗材推荐基本稳定 | 继续放开低风险品类 | | 人工驳回 | A供应商因品类冻结被驳回 | 补充冻结规则和供应商状态字段 | | 规则问题 | 老采购知道的红线系统不知道 | 把红线写成规则和审批条件 | | 使用问题 | 有人把Agent建议当最终结论 | 明确“建议、审批、执行”的责任边界 | 比如A供应商因为品类冻结被驳回，这件事不应该只停留在“Agent又错了”。采购负责人应该能在工作台里直接标记原因，并决定：把“品类冻结供应商不得推荐”沉淀为采购知识，把“办公耗材推荐前先查冻结和质量处罚”沉淀为团队记忆。 这时候AgentOps就不只是可观测性，而是用户自己的改进入口。它让采购团队看清楚：哪些是Agent的问题，哪些是主数据的问题，哪些是规则没有沉淀，哪些只是一次临时失败，应该留在trace里。 好的trace像一束光，照见Agent的路径，也照见业务系统里那些平时被灰尘盖住的角落。