来源与可获得性
本报告基于 AI Engineer World's Fair 2026 官方日程页、AI Engineer 发布的视频页面，以及 daily.dev 对该视频的结构化摘要和时间轴。官方日程确认了题目、讲者、公司、场次和 Graphs 赛道；视频页确认了 YouTube 视频 ID；daily.dev 摘要提供了演讲主线、时间戳和主题标签。
我没有找到官方公开发布的完整逐字稿。YouTube 自动字幕在本次抓取中需要登录验证，无法稳定取得；因此本文不提供“完整逐字中文翻译”。下面的“中文详述”是基于公开摘要、时间轴和可核验信息做的分段转述，不是逐字稿。
版权边界：如果未来拿到讲者或主办方授权的字幕/逐字稿，可以再补一版完整翻译。当前版本保留短标题和必要术语，不复刻整场演讲文本。
一句话结论
企业 AI 的长期护城河不是“用了哪个大模型”，而是组织把自己的业务对象、层级、规则、权限、历史文档和决策口径，沉淀成 Agent 能安全查询和持续修正的数据模型。
对企业
AI 项目要从“界面和 prompt”下沉到“数据模型和治理”。否则 Agent 只是漂亮地访问一堆不一致的数据。
对 WorkBuddy
WorkBuddy 不应只定位为办公 Agent，而应成为企业知识建模、工具接入、权限治理和评估闭环的工作层。
中文详述
演讲从一个护城河问题开始：在 AI 时代，模型会变强，模型调用会变便宜，聊天界面和 Agent 框架会迅速同质化。真正难复制的，是一家组织长期积累下来的隐性知识，以及这些知识如何被映射进可靠的数据结构。
0:00
护城河问题。Mike Phipps 把竞争优势从模型层拉回数据层：别人可以使用同样的 LLM、相似的 RAG、相近的 Agent UI，但无法轻易复制你组织内部对业务问题的理解方式。
2:32
SIP 的定位。Gates Foundation 建设 Strategic Intelligence Platform，目标不是做一个部门级报表，而是把约 4,000 人组织中的关键运营知识接到统一图谱中，让 AI 可以围绕组织真实语义回答问题。
3:46
数据规模。案例涉及 25 年 grantmaking 历史、每年约 70 亿美元投入、约 2,000 个 grants，以及人员、组织、投资管理、文档等多个系统的关联。
5:15
面向 Agent 的结构化。核心工作不是把所有数据塞进向量库，而是把 grant、funding、initiative、organization、person、document 等实体和关系建出来，让 Agent 可以沿着明确路径检索。
6:18
隐性知识显性化。数据拥有者知道“这个数该怎么算”“这个组织层级该怎么 roll up”“这个项目为什么属于某个战略方向”。这类知识如果不进入模型，Agent 会得到看似合理但业务上错误的答案。
7:09
治理与摄取。数据管道要处理来源系统、字段清洗、实体对齐、权限、PII、质量检查和版本变化。治理不是上线前的合规清单，而是整个知识图谱生命周期的一部分。
8:30
层级建模。资金和管理视角不是一棵简单树，而可能是可累加的 DAG：同一笔投入在不同管理口径下可以向上汇总，但必须避免重复计算和路径歧义。
12:32
跨系统缝合。人、组织架构、grant、投资组合和文档通常在不同系统中。SIP 的价值在于把这些孤岛实体缝合起来，让问题可以跨系统移动。
13:49
结构化数据 + 非结构化文档。文档不是独立的搜索对象，而是在摄取时被切块、标注、挂到图谱实体上。这样 Agent 检索文档时能知道它与哪个项目、团队、组织、时间和决策上下文有关。
15:34
通过 MCP 提供给 Agent。图谱通过 MCP 暴露给 Claude、ChatGPT 等 Agent。Agent 不直接乱查数据库，而是在受控工具和语义模型中生成查询、读取结果、组织答案。
17:31
评估反馈闭环。当 Agent 回答失败，问题不一定在模型，也可能在图谱缺字段、关系建错、口径未显式化、权限策略过宽或过窄。检索评估的结果会反过来推动数据模型迭代。
总结观点
- 数据模型是 Agent 的真实上下文窗口。长上下文可以装下更多文本，但数据模型决定 Agent 能否按业务语义找到正确路径。
- 知识图谱的价值不在“图”本身，而在可解释的业务关系。图数据库只是载体；护城河来自实体、关系、层级、口径和治理经验。
- RAG 不够，GraphRAG 也不够，关键是 operational graph。企业需要把运营系统、文档和权限放在同一个可查询语义层，而不是只做知识库问答。
- MCP 的意义是把数据模型变成 Agent 工具。MCP server 是边界：它包装查询能力、权限、工具描述、返回结构和审计，而不是让 Agent 直接面对所有底层系统。
- 评估应该反哺数据模型。每一次检索失败都要被归因：是问题理解错、图谱漏建、实体未对齐、权限限制、文档切分错误，还是业务口径本身未达成共识。
- 小团队可以放大组织能力。真正可复用的成果不是一次 demo，而是让更多员工通过同一套语义层安全访问组织知识。
WorkBuddy 如何实践
WorkBuddy 可以把这场演讲转化成一套企业 Agent 落地方法：先定义工作对象和业务关系，再接工具，再做受控问答和工作流，最后用评估持续修正数据模型。
| 实践层 | WorkBuddy 应该做什么 | 可交付物 |
|---|---|---|
| 业务对象建模 | 为客户定义核心实体：客户、商机、合同、项目、SKU、门店、供应商、工单、人员、制度、会议、文档。 | 企业对象字典、关系图、字段口径表。 |
| 层级与口径 | 把组织层级、财务口径、销售区域、品类结构、项目阶段等变成可遍历结构，明确汇总和去重规则。 | 层级 DAG、rollup 规则、指标血缘。 |
| 文档挂接 | 把合同、SOP、会议纪要、方案、报价单、培训资料切块后挂到实体，而不是只进一个全文搜索库。 | 文档摄取规范、实体标签、证据引用模板。 |
| MCP 工具边界 | 为 CRM、ERP、OA、知识库、BI、工单系统建立最小可用工具集，按角色暴露查询和动作。 | MCP 工具清单、权限矩阵、审计日志。 |
| Agent 工作流 | 把常见问题做成可约束流程：先识别实体，再查图谱，再取证据，再生成答案或动作建议。 | 工作流模板、系统提示、失败兜底规则。 |
| 检索评估 | 沉淀真实问题集，评估答案准确性、证据覆盖、权限正确性、查询路径和用户反馈。 | Golden set、eval dashboard、问题归因表。 |
建议的 6 周试点
- 第 1 周：选场景。选一个跨系统、重复高、答案需要证据的业务场景，例如“重点客户经营复盘”“项目风险周报”“合同与回款追踪”。
- 第 2 周：建对象。拉业务负责人一起定义实体、关系、字段口径和权限边界，先做 20% 高价值对象。
- 第 3 周：接数据。接入 2-3 个核心系统和一批关键文档，做实体对齐和文档挂接。
- 第 4 周：做工具。通过 MCP 暴露查询工具，限定输入输出结构，记录每次查询路径。
- 第 5 周：跑工作流。让 WorkBuddy 处理真实问题，要求每个结论带来源、口径和可追溯证据。
- 第 6 周：评估修模。用失败样本反推数据模型缺口，形成下一轮对象、关系和权限迭代清单。
风险与判断
- 不要把图谱当银弹。如果业务口径没有共识，图谱只会把分歧更快地暴露出来。
- 不要先追求全量。先围绕高频工作流建窄而深的模型，比铺一个大而空的企业知识图谱更容易出价值。
- 权限必须前置。Agent 能跨系统回答问题后，越权和 PII 风险会放大，MCP 工具层必须承担访问控制和审计。
- 评估要能定位到模型缺陷。如果只给答案打分，无法知道该改 prompt、改工具、改数据，还是改业务口径。