Agent的上限,可能不在模型,而在团队知识

核心结论(一句话)

团队 Agent 的长期能力不取决于囤积多少文档,而取决于能否把经验做成由流程生产、按场景注入、按消费反馈保鲜的知识供给系统。

分类提炼

知识节点

关联图谱

上游(基于 / 来自)

下游(应用于 / 验证于)

同级(横向 / 并列)

正文要点

1. 知识库从“仓库”变成“供给系统”

传统系统关心存了多少文档,Agent 系统更关心当前任务能否命中正确的少量内容。长文语义边界模糊会导致召回漂移;全篇注入即使命中也会浪费 token 并干扰推理。结构化知识应明确适用条件、结论和应做/不应做项,同时保持人机共读。

2. 先定义场景、消费者、内容和指标,再选择技术

原文用四问收敛目标:服务什么场景,谁消费且怎样消费,装什么知识,如何判断成功。它列出的指标包括注入命中率、画像覆盖率、盲搜下降率、返工下降率和对话采纳率。RAG、结构化存储、文档库和 MCP 都是实现手段,不能替代这些边界。

3. 用分层和自动化解决“知识产得出”

知识按公共基础、业务领域、场景策略、事件增量分层,避免把规则、背景和临时经验混在同一检索面。采集由流程节点自动触发、复盘 Agent 根据会话补洞、Agent 将事件转成结构化条目、运营处置即时入库四种机制并行完成。重点不是逼人贡献,而是减少额外动作。

4. 以准入、分级和生命周期控制可信度

“已上线 + 已关联仓库”是进入正式引用池的最小客观门槛;其后再用可用、待确认、待验证区分可信度。默认有效期、零引用归档与再引用复活共同构成知识代谢。过时知识比缺失知识更危险,因为它会以看似权威的方式误导 Agent。

5. 主动注入和消费记录把使用变成反馈信号

不同 Agent 只订阅对应知识包,例如需求评审消费需求模板和历史踩坑,运营 Agent 消费判定标准与 bad case。注入即记账,使系统能识别高频使用和长期未命中条目;复盘 Agent 再把会话盲点转为更新任务。关键是“使用数据反哺知识质量”,而非只提高文档数量。

实施检查表

先后 最小动作 可观测信号
1 选一个高频、可验收的 Agent 场景 明确当前返工、盲搜或命中问题
2 列出消费者、知识边界与四层目录 每类知识有来源和责任边界
3 在一个必经流程节点自动产出候选条目 人无需额外填写也有新增知识
4 设定上线/关联事实的准入门槛与可信度标记 Agent 不再引用半成品或未知来源内容
5 按角色主动注入并记录使用 能追踪每条知识的命中、引用和失效
6 用过期、零引用和未命中触发保鲜或归档 知识规模增长不等于噪声增长

证据边界

原文称其团队拥有 12 个研发 Agent、采用 90 天默认复校验,且将需求交付、代码审查和风险处置效率显著改善;还给出 99.7% 自动沉淀、90.2% 过期治理完成率、月 2,000 余次 Agent 调用等数字。上述均为作者团队案例自述,未独立核验。可复用的是问题框架、治理机制和度量维度,具体数值应由各团队自行建立基线验证。

相关链接