跨国深谈← 返回←LinkedIn 怎么让编码智能体真正读懂内部系统

LinkedIn 怎么让编码智能体真正读懂内部系统

关联

人物 Ajay Prakash

公司 LinkedIn

概念 编码智能体 · MCP · 剧本 · 上下文工程 · AI 基础设施

把一个线上事故的警报链接丢给编码智能体，几分钟后它不只找出根本原因，还会给出缓解步骤、代你执行、更新事件管理系统、再提一个修复代码的 PR——原本要几个小时的人工活，几分钟搞定。这不是演示视频，而是 LinkedIn 团队现在真实的工作方式。讲这个的，是 LinkedIn 软件工程师 Ajay,他介绍了公司内部的「Contextual Agent Playbooks and Tools」系统。

直接给智能体不够：企业场景的三大坑

编码智能体是在开源仓库上训练的，所以它们在 LinkedIn 这类大企业里水土不服：不了解内部框架、内部系统，工程师直接用会出现幻觉、中途卡住，甚至更危险——编造出不正确的东西。工程师手动写提示词去纠正，花的功夫比手动写代码还多，很多人干脆退回了手动编码。

LinkedIn 的技术栈有多大？超过 1,000 个仓库，组成数千个微服务，大量自建基础设施——自己的数据库、实验追踪平台、配置管理系统，全是外部模型一无所知的内部系统。

新工程师入职都要先上一周的培训营才能熟悉。所以他们给自己定的标准是：让任何编码智能体(Cursor、Claude Code、GitHub Copilot 都行)把内部系统理解到「写出的代码工程师能信任」——代码正确，质量不低于真正的工程师。

他们的第一步是搭内部 MCP(MCP 是 Anthropic 提出的、为智能体接入工具的行业协议)，第一个工具是 CodeSearch,把 LinkedIn 的跨仓库代码搜索开放给智能体。这是个强力解锁：你问「怎么设置某个东西」，智能体能自己搜出公司在LinkedIn 的标准做法，还能照着实现。之后陆续接入了 Docs、Jira、Slack、数据平台甚至功能开关，每加一个工具都产生复利效应——工程师可以把 PRD、设计文档、Jira 任务一起喂给智能体辅助编码。

但光有工具还不够，复杂工作流做不可靠。三个问题：①隐性知识散落各处——怎么调试某个错误日志这类知识散在文档、wiki、Slack 对话里，还常常过时、重复，智能体会迷失；②上下文过载——每个工具输出都占上下文空间，智能体被迫压缩上下文就会丢信息、从头再来；③没有持久记忆——每次任务都从零开始。

Playbooks:把「怎么干」也变成可调用的工具

2025 年初他们发明了 Playbooks:不仅通过 MCP 提供工具，还把指令和提示词本身也做成 MCP 上的资源。一个 playbook 就像一个普通工具，有名字和描述；智能体判断需要时调用它，里面的操作指令就作为工具输出返回。比如工程师问「怎么在 LinkedIn 设置一个 Airflow DAG」,智能体先调用对应的 playbook 拿到标准步骤，再按步骤调工具把活干完。

关键在于：LinkedIn 的任何人都能创建 playbook、提交到仓库、开放给全公司。为防止 playbook 泛滥失控，他们定了两条原则：一是自包含——一个 playbook 只做一个具体任务，这样智能体才能为任务挑对 playbook;二是拆小再引用——大 playbook 拆成多个小的、由大引用小，好处是可复用，加上「渐进式发现」：智能体只在需要时才读某个小 playbook,不用一次性吞下所有内容。这套东西和后来出现的 skills 概念很相似，但他们做在 skills 出现之前，而且通过 MCP 捕获组织上下文几乎零设置。

最巧的设计：智能体自己维护 playbook

知识库最大的问题是过时。他们的解法是让智能体参与维护：每次使用某个 playbook,鼓励智能体在会话结束时总结学到的经验——哪些信息过时了、哪里有出入、缺什么——然后自己检出仓库、更新 playbook、提 PR,批准后即生效。由此形成一个自我学习的飞轮。

架构上一个本地 MCP 服务器默认预装在所有 LinkedIn 笔记本上，每小时自动更新；playbook 分两层——中央 playbook 覆盖跨仓库的通用场景，本地 playbook 跟着各自仓库走、只在智能体于该仓库工作时被自动拾取。单一服务器还带来集中的认证和遥测数据，可用于持续改进。

还有一个 MCP 的通病要解决：直接呈现超过三四十个工具就会拖垮性能。他们的做法是用三个元工具替代全部呈现——先 search 按关键词和标签搜出相关工具/playbook(配合预配置的系统指令教智能体高效搜索)，再 get schema 拿到细节，最后执行。这让系统扩展到了数千个工具和 playbook。

规模与经验

现在每天有超过 8,000 名用户在使用，平台上有超过 1,300 个工具、600 多个 playbook——而且不只工程师，产品经理、设计师、TPM 都在用，各自带 playbook 进来自动化自己的工作流。

Ajay 留下两条核心经验：第一，从第一天起就把质量和可靠性当根本原则，而不只是生产力，系统才不会在扩张中劣化；第二，要为智能体构建正确的基础设施——在大型企业里，光把最新最好的工具和模型发给所有工程师是不够的，没有基础设施让智能体在企业环境内运作，它们发挥不了作用。

本集带走

• 工具之上还要给「操作手册」：把调试步骤、内部流程这类隐性知识做成智能体可调用的 playbook(它本身就是一种 MCP 工具)，智能体才能可靠地端到端干活，而不只是答基本问题。
• playbook 要自包含、要拆小：一个 playbook 只干一件事；大任务拆成多个小 playbook 互相引用，既可复用，又让智能体按需渐进读取、不撑爆上下文。
• 工具多了别全量暴露：超过三四十个工具就会拖垮性能，用「搜索 → 拿 schema → 执行」三个元工具替代，可扩展到数千个工具和 playbook。
• 让智能体自己维护知识库：每次使用后总结经验、提 PR 更新 playbook,解决知识库必然过时的老大难，形成自学习飞轮。
• 企业落地 AI 编码，基础设施是前提：上下文不足会导致幻觉和编造，工程师反而被提示词拖累退回手动——先补上下文基础设施，再谈生产力。

所以工程师们不得不手动给这些智能体写提示词，让它们做正确的事，而这往往比手动编码本身还要花时间。
So the engineers had to prompt these agents Manually, to do the right thing, which used to take more time than the manual coding itself.
—— Ajay Prakash · [04:37]

如果超过 30 或 40 个工具,我们就无法在不降低上下文质量或系统性能的情况下扩展。
We cannot scale it beyond 30 or 40 tools without degrading the context or degrading the performance of the system.
—— Ajay Prakash · [17:23]