2026年7月2日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

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

发布日期:2026-06-30 07:13:43 浏览次数: 1532
作者:欣逸AI

微信搜一搜,关注“欣逸AI”

推荐语

快速调教好Agent的关键在于实现可观测与可追溯,让AI真正成为生产力工具而非隐患。

核心内容:
1. B端场景下AgentOps的刚需与核心要求
2. 通过CI修复Agent的极端案例揭示问题本质
3. 一条最小可用的运行trace所揭示的具体改进点

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
对于大部分 C 端场景,AI 回答得不好,人可以换个问法,或者不用这段答案,厂商基本不用承担法律责任。
但 B 端不行,如果你给客户推荐的供应商、商品出现了问题(如不符合其公司红线要求等),人家是可能找你麻烦的。
所以 AgentOps 对 B 端,或者 C 端某些重要场景(如交易场景),非常重要,这就要求我们给用户的 Agent 要可见、可溯源、可归因、可复盘等
如果做不到这些,就直接给客户使用的话,那么就永远只能停留在助手的定位,不能真正成为客户的生产力。
举几个例子讲讲:



01

例子一: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.godiscount_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,而是让一次失败能变成下一次系统约束,持续优化团队的记忆、知识。
AgentOps 不是记录 Agent 干了什么,而是帮助团队判断它为什么这样干,成为团队持续进步的基石。



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 自己随手写日志(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_ Arule_2026_08
source_version
v122026-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_statusquality_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 的路径,也照见业务系统里那些平时被灰尘盖住的角落。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅