LinkedIn 想造出的那位值班同事
已经把 Claude Code 对向公司搜索、文档和工单的人，实际要问的是：内部流程为什么还是会卡住。被人叫做 AJ 的 LinkedIn 软件工程师 Ajay Prakash，是从这处卡住的里面作答的。MCP 工具能取回 LinkedIn 一侧的资料，智能体在步骤上仍然迷路。AI Engineer 频道上传的这场演讲，先把这段缺口当作失败来拆，再沿着 LinkedIn 在这些工具之上做的内部系统走一遍。
他把这件事称为上下文工程：塑造编程智能体能看见、能调用的东西，让它在 LinkedIn 内部干活，而不是做通用自动补全。开场是一段值班走查，他把它呈现为各团队已经在跑的生产故事。
负责关键服务的团队里，工程师还在摸清事故，就收到错误激增的告警。工程师把告警链接贴进 Claude Code 或 GitHub Copilot 这类编程智能体。人还在定位时，智能体取来公司的调试说明，认出受影响的服务，载入该服务的上下文，并拉来日志和指标。据此它提出根因和缓解步骤，然后等待确认。工程师确认之后的部分，Prakash 是这样描述的：智能体采取缓解动作，用细节、错误指标和仪表板更新事故管理系统，检出代码，并开一个对着根因的 pull request。
他说，这段循环把手工要花几小时的工作收成几分钟，并给这段走查贴上“不是虚构”的标签，还说 LinkedIn 的团队已经这样把编程智能体当作深知内部系统和代码的同事来用。按他的说法，支撑这套做法的系统是 contextual agent playbooks and tools。演讲其余部分讲他们为什么做、怎么做，以及学到了什么。
把通用编程智能体交给工程师为什么不够
LinkedIn 像许多公司一样把编程智能体发给工程师，Prakash 说，在大型企业里它们并不好用。他的诊断是训练数据的空档：模型在开源仓库上训练，缺少 LinkedIn 成熟的内部代码库、框架和系统。
他说，没有这些上下文，智能体就会产生幻觉、做到一半停住，或编出错误细节。工程师只好动手写提示，让它做对的事，花费常常超过自己写代码。许多工程师回到了手工编码。
按他勾勒的样子，这些智能体要学会的技术栈又大、又大多不公开。他说，LinkedIn 的新工程师光是熟悉这些系统，就要坐完为期一周的集训。他把这段入职当作类比，说明智能体也需要同样的组织上下文。
- 支撑着数千个微服务和应用的一千多个仓库
- 这些服务之下的内部框架和库
- 自建基础设施，例如内部数据库、实验与追踪平台，以及内部配置管理系统
标准：任何智能体，都要写出可信的内部代码
他们定下的设计问题是：Cursor、Claude Code 或 GitHub Copilot，任何一种编程智能体，能否把 LinkedIn 内部理解到足以交出工程师愿意信任的代码。Prakash 把这种信任定义成两点：代码应当正确，质量应当比得上工程师本人写出的代码。
这就是他说团队定下的标准。
内部 MCP 工具是第一道突破
Prakash 把第一道突破放在 2025 年初。他说，Anthropic 发布了 MCP，也就是把智能体接到外部工具上的 Model Context Protocol；它很快成为构建智能体工具的行业标准；LinkedIn 做了一个内部 MCP 服务器，第一个工具是全公司代码搜索。自动字幕滑成 “MCB” 和 “Cloud Code”；演讲里指的是 Anthropic 的 MCP 协议和 Claude Code。
LinkedIn 本来就有一套精细的代码搜索，能用关键词和自定义过滤器查询数千个仓库。把这套系统暴露到 MCP 上之后，智能体可以找到 LinkedIn 做某种配置的内部示例，并据此实现。Prakash 称之为一次大的突破：工程师问怎么配置，智能体可以搜 LinkedIn 的代码，而不必猜测。
他们接着又接上更多 MCP 面：文档、Jira、Slack、数据平台和功能开关。他描述价值是叠加上去的：工程师把产品需求文档（PRD）、设计文档和 Jira 工单喂给编程智能体。
工具仍然做不完事情的三个原因
接上这些工具之后，稍复杂的流程仍然失败。Prakash 说，有了工具，智能体能回答基本问题、找到代码示例。把一件事从头到尾可靠地做完，是另一条标准。
第一处失败是散落的内部经验。做完一件具体的事，得知道某个错误怎么修、某个系统怎么配、某段日志怎么查。这些知识散在文档、wiki 和 Slack 对话里，而且常常过时或重复。工具能取回这些材料。从里面拼出步骤是另一步。有了访问权的智能体仍然“迷路了”。
第二处失败是上下文过载。每一次工具结果都占用智能体的上下文窗口，也就是这场会话的工作记忆。会话最终必须压缩，把较早的内容摘要或丢掉，信息因此流失，智能体只好重做。
第三处失败是没有跨会话的记忆。即便智能体摸清了一项任务，下一位工程师再要同一件事，也得从头开始。playbook 后来把这一点做成仓库里的说明文件。
- 针对某个错误、配置或日志的内部经验，散落在文档、wiki 和 Slack 里
- 每一次工具结果都填满上下文窗口，直到压缩丢掉信息
- 解开的任务没有持续记忆，下一场会话重新开始
playbook：跟工具走同一条通道的说明
Prakash 说，2025 年初他们做出 playbook，让 MCP 既提供工具，也提供使用工具的说明或提示。每个 playbook 都表现为智能体可以调用的、带名称和描述的工具。调用之后，说明和上下文作为工具输出返回，智能体就从同一条通道拿到能力和指引。
他举的用法是：工程师询问在 LinkedIn 如何搭建 Apache Airflow DAG，也就是任务的有向无环图。智能体选定这项任务的 playbook，读返回的说明，再调用相关工具把事情做完。
LinkedIn 的任何人都可以编写 playbook，把它放进仓库，并提供给别人使用。
| 只有工具的会话里失败在哪 | 他说当时发生了什么 | playbook 打算改变什么 |
|---|---|---|
| 散落的内部经验 | 修错误、配系统、查日志的方法散在文档、wiki 和 Slack 里，常常过时或重复；能检索的智能体仍然迷路 | 一个具名 playbook 返回针对一项任务的自包含步骤 |
| 上下文过载 | 每一次工具结果都填满窗口，压缩丢掉信息，智能体重做工作 | 被引用的较小 playbook 只在需要时加载（渐进发现） |
| 没有跨会话的记忆 | 解开的任务在下一场会话从头开始 | 仓库里的 playbook 文件，在会话之后经 pull request 刷新 |
两条编写原则，以及和 skills 的比较
playbook 变多之后，Prakash 说他们要求所有人遵守两条基本原则。第一，一个 playbook 应当围绕一项具体任务自成一体，智能体才能选对。Airflow DAG 的 playbook 就停在这个 DAG 上。
第二，大的 playbook 应当拆成父级可以引用的较小 playbook。他说，拆开换来两件事：复用，因为一个小 playbook 可以被多个父级引用；渐进发现，因为智能体只在需要那一片上下文时才加载较小的 playbook。
他还把 playbook 和 skills 比较。skills 是一种行业做法：把说明打包，让智能体按需加载。Prakash 说，playbook 是同一个想法，LinkedIn 在 skills 出现之前就做了 playbook 系统，而且 playbook 更贴着组织上下文来收，几乎不用额外准备就能经 MCP 提供。
为了让 playbook 不变陈旧而鼓励的循环
他点出的知识库问题是变旧：说明会过时。被鼓励的智能体流程是：使用一个 playbook，在会话结束时找出学到的东西，也就是过时、不符或缺失的信息，更新仓库里的 playbook 文件，并开一个 pull request。
他说 pull request 之后 playbook 会更新。他称之为飞轮：智能体既使用公司说明，也刷新公司说明。
一台笔记本上的 MCP、中央 playbook、本地 playbook
按他的描述，分发方式是预装在 LinkedIn 笔记本上的本地 MCP 服务器。入职拿到笔记本时，服务器已经在上面。Prakash 说，服务器、playbook 和工具的更新每小时到达一次。
playbook 分成两类。中央 playbook 覆盖跨许多仓库的横切工作。本地 playbook 住在某个具体仓库里，只在编程智能体正在那里工作时被拾取，这样仓库特有的知识可以增加，而不必改动中央目录。
单一 MCP 服务器挡在所有 playbook 和工具前面，认证、遥测和学习就可以集中处理。
他们为什么不再列出每一个工具
把每个 playbook 和工具都列在 MCP 表面上，撞上了他视为 MCP 常见问题的规模上限：工具大约超过 30 或 40 个，上下文和系统性能就会变差。
他们使用的间接层，是放在目录前面的三个元工具。智能体按关键词和标签搜索，取回所选工具或 playbook 的 schema，然后执行该项。LinkedIn 为每个编程智能体预置系统说明，讲如何高效使用搜索和其他元工具。Prakash 说，这个设计让他们把工具和 playbook 扩到了数千。
- 预置智能体 LinkedIn 为每个编程智能体预置系统说明，讲如何高效使用搜索和其他元工具。
- 搜索 智能体用关键词和标签查询，在目录里找到相关的工具和 playbook。
- 获取 schema 对选中的一项，智能体取回调用它所需的细节。
- 执行 智能体运行该工具或 playbook，并把工具结果或 playbook 说明作为工具输出接收。
谁在用，以及给企业的两点结论
在台上展示的增长图里，Prakash 引用的数字是：工具和 playbook 的每日用户超过 8,000，playbook 超过 600。他还说，产品经理、设计师和技术项目经理（TPM）也在各职能里和工程师一起使用这些工具、带上 playbook。上传视频的标题把这场演讲包装成 “500 Skills, Zero Fine-Tuning”；口头演讲里既没有 500 个 skills 的数字，也没有不做微调的方针。
他的第一点结论是：系统能工作，是因为他们把质量和可靠性当作第一天的约束，包括在做出 MCP 服务器之前。他把这条原则描述为：在追求生产率的同时保证系统的质量和可靠性，这样快速推进时也不会下滑。
第二点结论，是说给已经接好 MCP 搜索和工单的在职开发者听的。他说，在大型企业里，如果公司不同时建造智能体能在其中运作的基础设施，最新的智能体和模型就会一直不起作用。这些基础设施就是 playbook、笔记本上的 MCP，以及让目录不至于灌满会话的元工具。
来源
相关来源
资料与编写依据
阅读了 AI Engineer 上传到 YouTube 的 Ajay Prakash 演讲的完整英文字幕（规范 URL https://www.youtube.com/watch?v=9wZpvF3QleU，视频日期 2026-09-09）。没有使用二次语音识别，没有 LinkedIn 官方文档，也没有独立的产品或性能核实。