企业 Agent 失败，不是因为模型不够大

Tesla 机器学习工程师 Ishita Daga 在这段 12 分钟分享里，把企业数据 Agent 的失败原因压到三个词：歧义、腐败、偏好。本文结合我自己的 Harness / 企业记忆笔记，讨论为什么加模型、加上下文、加知识库都不是根治方案。原视频：https://www.youtube.com/watch?v=B8l81jhvHbI

先说结论：企业 Agent 的问题是结构，不是智力

企业里一旦 Agent 答错，第一反应通常很一致：换更大的模型，换最新模型，塞更长上下文，再多挂几个知识库、Markdown、MCP server、plugin。

这些办法不是没用。它们能缓解一部分症状。但 Ishita Daga 这场分享的价值在于，她把问题从“模型不够聪明”拉回到“企业知识没有结构”。尤其是数据 Agent 场景，答错往往不是因为模型不会 SQL，而是它不知道哪张表才算准，哪个 KPI 定义还有效，哪个团队说“平均周期”时到底采用哪套口径。

这和我之前反复写的 Harness Engineering 是同一个问题：模型本身只是智能。让智能在企业环境里稳定产生结果，需要外层系统提供路由、状态、权限、验证、记忆和反馈。不是模型的部分，都是 harness。

Ishita 把失败原因拆成三类：

• Ambiguity，歧义：Agent 不知道该用哪个 source of truth。
• Staleness，腐败：上下文、流程、KPI 定义很快过期。
• Preference，偏好：不同团队对同一个指标有不同合法口径。

这三个词很朴素，但基本击中了企业 Agent 落地最烦人的部分。

歧义：知识库不是越多越好，关键是权威层级

很多企业做 Agent 的第一步，是把能找到的资料全部塞进去。Confluence、飞书文档、GitHub README、数据库 schema、BI 看板、客服知识库、历史工单、会议纪要，全都挂上。

问题是，Agent 不会天然知道这些来源之间的权威关系。

同一个“月活用户”指标，可能在 BI 看板里有一个口径，在财务报表里有一个口径，在某个团队周报里还有一个临时口径。人类员工知道哪个是正式定义，哪个只是当时为了汇报方便做的近似。但 Agent 看到的只是若干段文本和若干张表。

Ishita 的建议是建立 source of truth hierarchy：从最干净、最不灵活的来源开始，再逐步退到更灵活、更混乱的来源。她给了三层：

这套分层很实用。因为它不试图让 Agent “自由理解整个公司数据库”，而是先给它一条默认路径：能用语义层就别猜表；语义层不够，再用 canonical query；最后才进入数据库图谱。

我会把它翻译成一句更工程化的话：不要把知识库当平铺文件夹，要把它当路由表。

这和个人知识库里的索引分片也很像。一个薄入口先判断问题类型，再路由到 analysis、concepts、sources，而不是让模型每次把几百篇笔记一起揉进上下文。企业 Agent 更需要这种结构，否则文档越多，冲突越多。

腐败：上下文会烂，必须有生命周期

第二个问题是 staleness。这个词比“过期”更狠一点：上下文不是静静地失效，它会腐烂。

企业定义变得很快。KPI 改口径，流程改审批链，字段被废弃，团队临时加过滤条件，某个看板下线但文档没人删。Agent 如果还拿半年前的 Markdown 回答，就会非常自信地给出错答案。

很多团队的处理方式是“让某个人记得更新文档”。这基本靠不住。企业 Agent 要稳定运行，不能把上下文更新当成手工卫生习惯，而要把它做成生命周期。

Ishita 提到两个组件：

1. 接入 live data sources：比如 GitHub、CRM、Tableau、dbt semantic layer。重点不是来源多，而是这些来源本身被持续维护、审核、更新。
2. 建立 feedback loop：每一次“这个数据库不对”“这个定义改了”“这个指标要加过滤条件”，都应该被记录、评估，并反哺 Agent 上下文。

这里最容易被忽略的是第二点。很多企业 Agent 有 retrieval，没有 learning loop；有知识库，没有纠错账本。用户纠正了一次，下一次还是犯同样的错。

这和 Codex 自动化里的 inner / outer loop 很接近。Inner loop 负责带着上下文完成任务；Outer loop 从人的审查、修改、拒绝里回收新的上下文。关键不是“每次都改 prompt”，而是把 diff、纠错和取舍变成证据，攒够模式后再更新规则。

企业数据 Agent 也应该这么做：

• 用户说“这张表不该用”时，不只是本次回答道歉，而是记录一次 source-of-truth 事件。
• 用户改了 SQL filter，不只是重新跑查询，而是判断这是个人偏好、团队偏好，还是全局定义变化。
• 指标答案被业务否定，不只是换模型，而是进 evaluation suite，成为以后回归测试的一部分。

没有这个循环，Agent 每次都是新员工。它也许聪明，但不会长记性。

偏好：最难的是“两个答案都对”

第三个问题最麻烦：preference。

如果某个答案明显错了，还能靠验证、测试、回归集解决。但企业里更常见的情况是：两个答案都对，只是属于不同团队。

Ishita 举了一个例子：计算某个 milestone 的平均耗时。

• Team A 用“上一个 milestone 完成 → 当前 milestone 完成”。
• Team B 用“当前 milestone 开始 → 下一个 milestone 开始”。

这两个定义都可以成立，但结果会完全不同。Agent 如果只问“平均 milestone time 是多少”，它必须知道提问者是谁、所属团队是什么、当前场景是什么。否则它没法判断该用哪套口径。

这就是企业记忆里最难的一层：同一份事实，在不同角色和业务视角下有不同含义。

我之前看 Sentra 关于企业记忆的观点，也是在讲这个：企业需要一份共享 substrate，再叠加多个 lens。底层事实可以相同，但销售、财务、运营、法务看到的是不同对象。供应商延迟这件事，对采购是风险，对财务是应计，对运营是排产问题，对法务是合同暴露。

数据 Agent 的偏好问题也是如此。不是把所有历史聊天塞进 memory.md 就能解决。记忆只知道“某人上次说喜欢 A 口径”，但它未必知道 A 口径适用于哪个指标、哪个团队、哪个场景，也未必知道何时该让位给全局标准。

Ishita 提到两个不完全方案：

• 把所有指标算法都放进 semantic layer，让用户明确指定要哪一个。
• 用 agent memory 记录用户偏好。

前者解决了定义可选，但没有自动路由；后者记录了偏好，但很难理解指标之间的语义差异。真正想要的是：Agent 能根据“谁在问、问什么、在哪个业务上下文里问”，自动路由到正确指标定义。

这也是为什么 preference 不是一个简单的记忆功能，而是 ontology 问题。

企业 Agent 的三层修法

把这场分享和已有笔记合起来，我会把企业 Agent 的改造路径压成三层。

1. 先建权威路由，不要先堆资料

所有知识源先分层：正式语义层、标准查询、动态表图、历史文档、聊天记录。每层标清楚权威性、更新时间、适用场景和 fallback 顺序。

Agent 的默认动作不应该是“搜索所有资料”，而应该是“按权威顺序找答案”。这是最小但最有效的改造。

2. 把纠错变成事件流

用户纠错、SQL 修改、定义更新、指标争议，都要落成事件。事件再进入评估、上下文更新、规则调整。

这里不需要一开始就做很复杂。哪怕只是三类事件也够用：

• source 错了：哪张表 / 哪份文档不该用；
• definition 变了：指标、字段、过滤条件发生变化；
• preference 出现了：某团队在某场景下采用特定口径。

每个事件都要能追溯到原始对话或工单。否则后面全是传话。

3. 为偏好建 lens，而不是写一堆特例

偏好不能全靠 if/else。企业需要显式建模角色、团队、场景和指标定义之间的关系。

一个比较现实的起点是：

• 全局标准定义放 semantic layer；
• 团队覆盖定义放 team lens；
• 个人偏好只作为弱信号，不直接覆盖全局标准；
• 冲突时让 Agent 说清楚采用了哪套口径，并给出切换选项。

这样 Agent 至少不会把“销售团队习惯”误当成“公司标准”。

为什么这比换模型更重要

更大的模型当然有帮助。它能更好地写 SQL，更好地理解自然语言，更好地处理长上下文。

但企业 Agent 的失败很多不是推理失败，而是治理失败：没有权威层级，没有更新生命周期，没有偏好本体论，没有评估闭环。模型越强，只会让错误看起来更自然。

这也是 Harness Engineering 的基本判断：模型包含智能，harness 让智能可用。企业场景里的 harness 不是漂亮的 agent framework，而是一组很无聊但很关键的制度：source routing、context lifecycle、feedback loop、evaluation suite、memory ontology。

如果这些东西没有，Agent 就会变成一个读了很多文档的实习生。它知道很多，但不知道哪句算数。

真正的企业 Agent，不是“会回答问题”的聊天框，而是能在组织知识结构里定位自己：知道哪里是权威，知道什么时候该更新，知道不同团队为什么会要不同答案。

这才是结构问题。

资料来源

• 视频：Ishita Daga, Enterprise Agents Have a Structure Problem, AI Engineer, 12:07, https://www.youtube.com/watch?v=B8l81jhvHbI
• 关联笔记：Harness Engineering、企业记忆 substrate + lens、Codex inner / outer loop、分层符号化记忆