跨国深谈← 返回←智能体为什么总是新员工？给它们造一个上下文引擎

智能体为什么总是新员工？给它们造一个上下文引擎

关联

人物 Peter Werry

公司 Unblocked

概念 Claude Code · 上下文引擎 · 智能体 · 上下文窗口 · 代码评审智能体 · 搜索满足感

把一个专家级工程师招进公司，但他每次接任务都是「第一次入职的新员工」——每次都要重新发现你的代码库、你们怎么做测试、怎么部署。这就是今天所有编程智能体的处境。这一场演讲的主角是 Unblocked 的一位演讲者（Unblocked 是一家构建「上下文引擎」的公司），他讲的正是这个问题的解法：给智能体接上一个上下文引擎，为人类员工和智能体提供组织上下文。

智能体的真正瓶颈不是模型，是上下文

多年以来，人类工程师自己就是「上下文层」：在各个数据源、讨论串和代码库之间翻找，靠应对事故和写文档慢慢积累起「部落知识」。智能体面对同样的挑战，但更糟——它们每开始一个新任务，知识就重置一次。

演讲者给了一张「AI 成熟度曲线」：从早期 GPT 时代的自动补全（还记得 Copilot 吗），到 Cursor，再到试图解决上下文问题——有人建组织维基，有人给智能体配 MCP 和 skills 教它们怎么找信息。大多数人现在处于第四到第五阶段，已经意识到上下文是瓶颈。而终点是第八阶段的「软件工厂」：智能体要全面自动化，没有组织上下文根本无法运作，它们会迷失方向。

核心问题一句话：获取信息不等于理解。挂一个维基给智能体，它还是不知道需要的信息在哪。

而且它会患上放射科的「搜索满足感」——看 X 光找到一个可疑病灶就停手，错过其他更重要的指标。智能体也一样：找到某个看似正确的东西，就停了。它们也不会提炼理解：能找到信息，却不明白各部分怎么拼合、依赖之间如何互动、架构规划会怎样约束接下来的工作。

那把整个代码库加架构文档全塞进上下文窗口行不行？实践中不行：组织上下文远超百万 token 的窗口容量，而且会让智能体分心——干活需要的是针对任务的专注流，东张西望只会浪费 token 和时间。

冰山之下是智能体看不到的东西：真实意图、团队约定、过往决策、Slack 里讨论过的内容、架构背后的理由。这就是为什么智能体需要一个上下文引擎才能干真活。

现场演示：同一个问题，有没有上下文差别有多大

上下文引擎的第一层价值是服务人类——人类层并没有消失，最终问责止于人：你在 PR 上点合并之前，必须理解它在干什么。演示里问一个关于内部 SourceMark 引擎的问题，系统不仅能把架构讲清楚，连架构图都是根据代码现状现场推断生成的，还能给出未来架构提议。关键的是它「展示工作过程」——这首先是建立信任，其次如果答案不完全对，人可以去知识库里纠正。

然后是重头戏：同一个任务，让 Claude Code 生成优化 SourceMark 计算器的计划——

• 不带 Unblocked：Claude Code 自己翻代码、推断算法，结论不错，但抓不住细微差别；耗时约两分钟，成本更高。
• 带上 Unblocked：它抓住了团队在 PR 里讨论过的未来改进可能、Slack 对话、Notion 和架构文档，计划直击要害；总成本不到一美元，约一分钟。

而且这些来源会回传给 Claude,Claude 确切知道接下来该跳到哪里深挖。短任务上的差距还只是小头，真正的价值在累积效应：不带上下文时，智能体不仅要多花工作去发现东西，发现的还不是正确的东西——执行到深处才发现自己在错误的计划或假设上运行，然后返工、循环往复。「循环会累积，你必须全程让上下文保持高效」。

组织上下文不只是数据，还是智能

Unblocked 还有一个代码评审智能体。它从拉取请求数据里生成一系列最佳实践，帮助智能体与你的代码库对齐。

演示里它发表的意见让工程师 Richie 说「这像是我会说的话」——因为这确实是他之前说过的话，系统调出了他的历史评论。他们还用资历和专业度做信号，给重要评论加权。

更神奇的一幕：Richie 发现代码评审问题数量急剧下降，和 Unblocked 一起调试，追到底后让云端运行的 Unblocked 智能体去修——它不仅生成了修复 PR,还把因果关系讲清楚了：切换到 Claude 4 之后评审行为变了，问题才下降。它甚至找到了那段关联的 Slack 对话，把全部历史串起来，最终产出一个带完整上下文的 PR。

开源工具与你能上手的东西

演讲者最后给了几个可以直接玩的东西:

• Document Query Engine（开源）：跑在你的 GitHub 仓库上，摄取历史 PR,基于可采样的文档合成一个 schema,然后就能随意查询、通过智能体聊天获得各种洞察。
• 工程社交图谱（开源）：从代码评审关系里聚类出团队结构和专家覆盖，连成线的就是互相评审代码的人。可以生成团队标签，也能看出哪里缺乏专家覆盖——这正是上下文引擎内部用的东西。
• 上下文引擎模拟器：不想注册 Unblocked 也可以试，它对每个任务在后台构建上下文，再用/不用上下文各跑一遍，让你直观看差异。

收尾引用一位客户的话：「token 减少 50%,分类更快，答案更好。」

本集带走

• 智能体像每次都重新入职的新员工：每个任务都重置知识，必须重新发现代码库、测试和部署方式——这是智能体干真活的根本瓶颈。
• 获取信息不等于理解：挂维基没用，智能体会有「搜索满足感」（找到一个答案就停）也不会提炼理解；全塞进上下文窗口则容量不够且让智能体分心。
• 上下文的价值在累积而非单次：带上组织上下文，生成计划更快更便宜；不带的话智能体会在错误假设上越走越深、返工循环。
• 「展示工作过程」是信任机制：答案附上来源，人能核对并纠正，来源还能帮智能体自己决定下一步深挖哪里。
• 上下文引擎 = 数据 + 智能：从 PR 历史提炼最佳实践、用资历做评论权重、用评审关系构建工程社交图谱找专家盲区——这些都能上手（开源的 Document Query Engine 和工程社交图谱，以及上下文引擎模拟器）。

智能体就像新员工。每当你开始一个新任务时，它们的知识都会重置。
Agents are like new employees. They reset their knowledge every time you start a new task.
—— Peter Werry · [01:54]

你可以把一个智能体想象成一位专家级软件工程师，但每次都是第一次入职的新员工。
You can think of an agent like an expert software engineer who’s a new employee onboarding for the first time every time.
—— Peter Werry · [02:03]

获取信息不等于理解。
Access to information doesn’t equal understanding.
—— Peter Werry · [04:13]

这就是为什么你的智能体需要一个上下文引擎才能完成真正的工作。
And that’s why your agents need a context engine to get real work done.
—— Peter Werry · [06:59]

循环会累积。而你必须在整个过程中都让上下文的使用保持高效。
The loops compound. And you have to be efficient the entire way through with your context.
—— Peter Werry · [12:25]

token 减少 50%,分类更快，答案更好。而这正是上下文引擎能做到的。
50% fewer tokens, faster triage, better answers. And that’s exactly what a context engine can do.
—— Peter Werry · [17:45]