Tim O'Reilly 对谈 O'Reilly CTO：用专家框架让 AI Agent 帮组织变聪明而非更快

O'Reilly Radar·2026-10-31 00:54· 25 分钟前AI 评分66

更智能，而不只是更快

AI 导读

Tim O'Reilly 与 O'Reilly Media CTO Andrew Odewahn 对谈其 Expert Intelligence 工作：该工具把 AI Agent 通过 MCP 连接到组织的信息系统，用技能文件指导推理，并以 O'Reilly 图书中的专家框架为分析提供依据。

正文 · 原文

本活动摘要由 Claude 生成，经 Tim O'Reilly 少量编辑，基于活动文字记录。

2026 年 10 月 15 日，Tim O'Reilly 主持了与 O'Reilly Media CTO Andrew Odewahn 的一小时对谈，这是 Live with Tim O'Reilly 的一期节目，该访谈系列在 O'Reilly 学习平台上直播。Andrew 在 O'Reilly 工作多年，最初是作者，随后为公司平台构建工具，最终担任 CTO 兼工程负责人。过去一年里，他的团队一直在构建公司所称的 Expert Intelligence，这是一套工具，将 AI agent 连接到组织自身的系统，给它一个技能文件，描述如何对在那里发现的内容进行推理，并让它的分析以 O'Reilly 图书馆中的从业者框架为依据。Andrew 在最近一篇 Radar 文章《Building Organizational Intelligence》中描述了这项工作。

Tim 和 Andrew 的访谈围绕一个分为两部分的演示展开，第一部分关于研究 agent，第二部分关于 Andrew 团队构建的用于审查其产出的系统，中间穿插讨论，全程有观众提问。

Tim 以一个他说 Andrew 的工作有助于回答的问题开启了对话：AI 故事的大部分内容都关于效率，即更快地完成同样的工作。那么，一个组织变得更智能是什么样子？

构建研究 agent

Andrew 的研究 agent 源于个人需求，而非战略。他想知道一个项目的状态，例如，从 RabbitMQ 迁移到 Pub/Sub 需要多长时间。这是每个工程师都害怕、但每个工程负责人都必须回答的问题。他还有一个更广泛的担忧：单个人擅长 AI，并不等同于一个组织擅长 AI。

他分四步构建了自己的 agent。他将组织的信息系统映射为一个层级结构，通过 MCP 将它们连接起来，编写了一个技能文件告诉 agent 如何使用它们，最后添加了 Expert Intelligence 层。

工程组织工作流中事实来源的映射图是其余部分得以奏效的关键。Andrew 将它们按顺序排列，并向模型解释它们之间的关系：战略目标和功能优先级位于 Productboard。它们变成 Jira 中的 epic、sprint 和 story。story 变成 GitHub 中的代码。服务目录描述了构成 O'Reilly 平台的大约 300 个服务以及谁拥有它们，可观测性工具则显示这些服务相对于其 SLO 的表现。该技能文件还必须编码本地惯例。有些团队用结束日期将 epic 标记为完成，而另一些团队则在所有工单关闭时认为它已完成。Andrew 还告诉 agent，它是一个研究 agent，而不是编码 agent，它的工作是撰写报告。

用他的话来说，通过 MCP 连接一切是“整个过程中最完全乏味的步骤”。当时 Productboard 没有 MCP 服务器，所以他写了一个封装器。后来，当 Tim 问到另一家公司如何用不同的工具集重复这项工作 Andrew 建议从供应商列表入手。从你的采购系统中导出它，让模型说出这些供应商生产什么产品、哪些产品会包含与你关心的问题相关的信息，并让它把它们排好序。O'Reilly 的产品经理们现在正把这一流程转化为即将推出的 Expert Intelligence Skills Hub 的一项技能。

一位听众问到，与语义搜索相比，MCP 是否真的是适用于内部知识的正确工具。正如 Andrew 所指出的，有时候有总比没有好。归根结底，你想要的是让模型能够在你的各个系统中进行搜索。

从招聘案例到琐务审计

演讲的核心是 Andrew 此前在“Building Organizational Intelligence”一文中写过的那个特定用例的前后对比。一位工程经理请 Andrew 再招一名工程师，Andrew 便让他的报告与分析智能体来撰写招聘论证。第一份报告涵盖了管理内容与元数据的五人团队、该团队拥有的 10 项 A 级服务及其 B 级和 C 级服务、Pub/Sub 迁移的进度（已完成 64%）以及完整的待办事项。报告的结论是，该团队存在产能问题，可能应该招人。Andrew 称其有用且非常详细。. .“也许过于详细了。”

随后，他把该智能体连接到 Expert Intelligence，让它像顾问一样行事，并重新运行了分析。新报告得出了截然不同的结论。报告开篇指出，该团队的运维开销问题是“结构性的，而非人员不足”。在咨询 Expert Intelligence 时，该智能体引入了 Google 的《Site Reliability Workbook》中“琐务”（toil）的概念。琐务是指随服务规模线性增长的手动、重复、可自动化的运维工作。报告与分析智能体利用这一概念，将该团队的待办事项拆分为琐务和人们真正想做的工作。它建议在下一个规划周期之前进行一次结构化的琐务审计，设定明确的琐务削减目标，并将运行手册的所有权视为一等工程产物。Andrew 说，该团队采纳了这些建议，并清掉了相当一部分一直压在所有人身上、构成认知负担的待办事项。

报告接着引用了《敏捷宣言》签署人、《Wild West to Agile》的作者 Jim Highsmith 的观点，论证该团队的技术债务正在不断累积。Andrew 解释了这与通常的管理建议有何不同：

很多时候，当你读到这些高概念框架时，感觉就像在吃西兰花。我确实应该那么做。但真正让这件事有意思的是，它挑出了我们手头的一个具体项目——Django 升级，并把它放进了这个更宏大的框架之中。它不只是说‘这里有一条你应该应用的抽象原则’，而是说‘这是你的待办事项，这是一个具体的例子’。”

第二项分析考察了跨越团队边界的服务。它借鉴了微服务专家和 Kent Beck 关于耦合的研究（见Tidy First?），将视频元数据服务诊断为复杂子系统问题，而非边界问题。在这个版本中，Andrew 让智能体提取引文、标注出处，并链接到源文本。由此产生的分析效果显著。此后，该公司已停用了几个系统。“我不需要 LLM 来添加代码，”Andrew 说，“我希望它们减少代码。”

Andrew 说，最让他意外的是同事们的反应。他早先的报告只是数据堆砌。读者无法判断任何一条论断的来源，因此可操作性大打折扣。当分析引用了工程师们从自身工作中熟知的专家时，这些文档就变得——用他的话说——“平易近人得多，人性化得多”，人们也更深入地参与其中。

Tim 的回应：召唤专家

Tim 插话，将这次演示置于背景中。他将其与一种观点形成对比：模型现在已经足够聪明，你只需告诉它做什么，然后放手让它干——我们从氛围编程者和主张“黑暗工厂”的人那里经常听到这种说法。Tim 则主张回归专业能力。

他引用了 Anthropic 的 Felix Rieseberg 当天发表的一篇文章《如何更有雄心：面向使用模型的人类教程》，其中描述了与模型协作时的四种雄心：速度、高度、深度和广度。关于 AI 经济价值的大多数讨论都围绕速度，即用更少的时间完成同样的工作。在 Tim 看来，Andrew 仅仅通过召唤专家，就获得了高度（思考结果而非任务）和深度（以领域顶尖专家的方式处理问题）。

Tim 随后提出了一个他酝酿已久的比喻：AI 编程如同施展魔法咒语。在漫威漫画和电影中，奇异博士通过召唤某种源头来开启咒语，比如“以可怕的 Dormammu 之力”或“以 Hoggoth 的古老众神之名”。他说，Andrew 做的正是同样的事，实际上是在说：“以 Kent Beck 之力，我要你以不同的方式思考这个问题。”即使在 Andrew 没有点名专家的地方，比如 SRE 工作手册，仅仅让模型指向 O'Reilly 出版经典中所体现的专业知识，就提高了智能体产出的标准。

Tim 将此描述为将人类专业知识用作聚焦机制，并将其与他的一项论点联系起来：LLM 更适合被理解为我们用以创造的媒介，而非独立的智能。他还反驳了一种常源自“苦涩的教训”的观点，即模型只会越来越好，人类专业知识将不再重要。他说，Andrew 找到了它依然重要的一个具体方式。

Andrew 接过了这个比喻。他说，他自己的第一个提示词是：“要势利。去找这些伟大的资源并看看它们。”他想把某个领域的经典著作交给模型，比如Designing Data-Intensive Applications，并告诉它“这些是我希望你思考问题的方式”，而不是接受模型最先想出的任何东西。他将其比作商学院，你在那里学到的大部分内容是一套组织事实的框架。

模型在没有方向指引时会怎么做

Tim 认为，模型在无人提示的情况下并不会发挥出最佳水平。他说，观察它们搜索信息时的思维链，你可能会看到它们随便从互联网上找了一个随机文件，而不是权威来源。即便是像 Fable 这样的前沿模型，他自己的经历也充满了反复试错和错误——模型靠蛮力硬推出一个解决方案，而未必知道该如何着手。

Andrew 讲了几天前的一个故事。他让智能体审查工程团队和产品团队的激励计划。

返回的数据是：“根据 Robusto 公司（我相信这是一家很棒的公司）的说法，这就是框架，你们真的应该照他们做的来做。”我心想：“Robusto 是什么，我为什么会看到这个？”然后我意识到，哦，我没连上 VPN。于是我连上了，结果突然就变成了：“根据 Harvard Business Review，这些是设计这些激励计划的不同方式。”这是一个非常强大的模型。但它抓住了它找到的第一样东西，然后说：“这就是我思考这个问题的方式。”

Tim 提出了一个经济层面的问题。他指出 Anthropic 的 Claude 系统提示词中有指令限制了模型可以从任何来源引用的内容量，并将其解读为 AI 公司想要避免为内容付费的信号。他认为，结果是模型无法足够具体地利用它们所能获得的最佳材料，而往往退回到泛泛而谈。他称这是 AI 中“垃圾化”的早期形式。

O’Reilly 持相反立场。Andrew 解释说，公司沿用了它已经用于 O’Reilly Answers 的版税模式。通过 Expert MCP 服务器返回的材料可以被引用，作者会因此获得版税，这样专家内容就有了市场并获得了回报。

在回答观众提问时，Tim 和 Andrew 指出，Expert Intelligence 正与一组创始合作伙伴进行预发布，同时 O’Reilly 正在厘清其经济模式。有兴趣的组织可以通过产品页面申请访问。

把讨论放到 AI 能看到的地方

Andrew 演示的第二部分涉及智能体写完报告之后会发生什么。决策需要共识，而面对 AI 生成的分析，人们需要检查模型是否抓住了不重要、过时或误解了的东西。“AI 可以识别所有的权衡取舍，”他说，“但人们仍然需要做出真正重要的决策。”

他的团队最初以 Google Docs 形式分发报告，但遇到了两个问题。一份正在被审阅的文档中最有趣的部分通常是评论线程，而由于目前 O’Reilly 的公司政策不允许 MCP 连接到 Google Docs，智能体看不到它。而当 Andrew 让模型把讨论合并回文档时，粘贴结果会抹掉评论。

O’Reilly 的工程总监 Doug Hogan 在 Git 和 GitHub 之上构建了一个替代方案，Andrew 称之为 SuperAnswers。（Andrew 开玩笑说，这就是为什么不允许他来命名东西。）文档存放在 Git 仓库中，讨论发生在 GitHub Discussions 中，每一次变更都有版本记录。Andrew 可以问他的智能体某个项目的共识是什么，让它把评论整合进新草稿而不丢失历史记录，之后还能重建某个决策是何时做出的、以及当时人们知道些什么。同一份记录还能让他生成某个决策所需的衍生文档，比如面向工程、产品和设计团队的范围说明，或者一份会议议程。一个图谱视图会把人们正在讨论的主题聚类，并标出仍未解决的决策。

Tim 把整个系统总结为一个研究助手，它连接到组织的真相来源，一层外部专业知识用来把发现置于背景中，还有一个共享的、带版本的讨论，逐渐成为不断演进的组织知识库，这使 AI 成为更有用的同事。Andrew 表示同意，并说他愿意将 SuperAnswers 开源，他将其描述为 Git 之上的一层薄薄的封装。

Andrew 还指出，他所应对的碎片化并不限于工程领域。销售团队的信息分散在 Salesforce、6sense 和 Gainsight 等系统中，每个职能都有同样的需求，要把这些线索汇聚起来。Tim 补充说，整个行业的工具可及性并不均衡，而且一直如此。Claude 生成的 PowerPoint 比 Google Slides 更好，Gemini 则相反，组织必须积累关于自己工具集的这类知识。

观众提问

一位名叫 Thomas 的观众担心，员工现在是与 AI 对话而不是彼此对话，工作消失在“那个 AI 黑洞”里。Andrew 说，他倾向于把所有东西都放在 Git 里，部分原因正是对此的回应，因为它为人类和 AI 提供了一个中心位置，用来查找和重建过去的工作。但他更大的兴趣在于人类之间以 AI 支持的方式进行交流。他描述了一类他以前从不问的问题：

我知道，如果我问这个问题，就得有人花两周时间从所有这些不同的系统里把这些东西汇编起来。现在几分钟就能收集好。也许其中一些是一次性的，但如果成本很低，那也不坏。

针对“一次性”这个说法，一位观众在聊天中写道：“Andrew，这不是一次性工作。这是一个产品负责人，把价值主张朝积极方向改变了。太牛了，兄弟。”Tim 忍不住把这条大声读了出来！

当 Tim 问他哪里做错时，Andrew 承认，他没有足够早地考虑人们会如何审阅和回应 AI 生成的文档。人们不想费力去读 AI 生成的数据堆砌，而且他们不会给 AI 任何疑点利益。如果一份 AI 撰写的报告在 Kubernetes operator 上弄错了一个小事实，读者很可能会否定整份文档。AI 工具必须被理解为整理和呈现证据，而不是做决策。“这些需要支持你的分析能力，而不是取代它。”

Tim 把这个回答与对技能退化的担忧联系了起来。他描述了自己与 Fable 尝试的一个微调项目，目的是训练一个小模型，让它写得更像自己。他想理解每个阶段，而不是让模型自行运行，但模型从未解释这些阶段，训练运行也失败了。部分原因是模型要求他提供自己的写作样本，却没有充分说明一个真正好的训练数据集应该是什么样，因此这些样本针对性不够。它们太长了，而当 Fable 挑选它实际需要的短片段时，又做得不理想。

当 Tim 用仍在开发中的工具 O'Reilly Tutor 尝试同一个项目时，它让他去读 O'Reilly 上关于好的训练集应该是什么样的一份资料，他意识到自己错在哪里。Tim 把人们把工作直接交给 AI 时可能发生的那种技能退化，比作再也看不懂地图的人，或者为了一点自己只要多了解一点原理就能在 30 秒内搞定的小修小补而叫水管工的人。他认为，每个人都有义务在使用工具的同时持续学习。

一位名叫 David 的听众——一名正在寻求技能重塑的失业工程师——提出了类似的观点。我们过去是知道东西的，后来我们搜索，现在我们跳过搜索，直接要答案。他问如何建立真正的深度。Andrew 建议选一个项目，把它各个方面都做一遍，让 AI 充当导师（他正用这种方式重新学微积分），同时手边放一本书，或者利用关于快速变化主题的讲师主导的直播活动。

对话以这样一个区别结束：一个只是让组织更快的 AI 系统，与一个让组织更善于决定该做什么的 AI 系统之间的区别。在 Andrew 的叙述中，更善于决定需要做哪些工作取决于模型自身无法提供的三样东西：一张组织知识所在位置的地图、一套人们信任的专业知识，以及一个人类可以与 AI 产出进行争辩的地方。

你可以在 O'Reilly 学习平台、 YouTube 或任何你获取播客的地方观看《Live with Tim O'Reilly》的完整剧集，包括这一集。

来源：O'Reilly Radar · oreilly.com