专栏 · Agent 工程手艺 › 第 194 期 · AGENT 工程 · 收录于 2026 年 8 月 23 日
搭 Agent 已经不难了,上下文才是下一个前沿——Jeff Ng(Unblocked)
2,678观看
59赞
2.2%点赞率
7评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一搭 agent 已经不难了：六个月前要一个团队干一个季度交的那些「税」（状态持久化、沙箱、可观测性），如今被云厂商原语 + 框架兜住，定义一个 agent 只剩选模型、写指令、给工具、给 skills、定沙箱五件事。 → 详细
- 二难的是 agent 仍会「一本正经地犯错」：Linear 工单 agent 建议重启的开关几天前刚引发过故障——它缺的是 Slack 复盘讨论和 postmortem 工单；本地不翻车只因为人在每一轮当「上下文层」给它当保姆，一旦做成后台 agent，错误会悄无声息地扩散。 → 详细
- 三替代人的那层就是 context engine：连上文档/代码/工单/对话建组织模型，只给 agent 一个调和、排序、限权后的「可行动的理解」而非文档列表；MCP 只解决访问不解决理解——「差距不在智能，而在上下文」。 → 详细
01
六个月前搭一个 agent 要一个团队干一个季度——因为 agent 不只是「模型 + 工具」
- Jeff Ng 是 Unblocked 的创始工程师（founding engineer）。开场立论：搭 agent 这事已经变得相当容易，但 agent 还是会「一本正经地犯错」（confidently wrong）。六个月前，做出一个 agent 得靠一整个团队、花差不多一个季度。 → 详细
- 原因在于「agent 不只是模型和工具，而是模型、工具，再加上把它做成生产级服务所需要的一切」。他放了一张当时必须搭起来的系统清单，每一项「基本上都够成立一家公司，或至少是公司里的一个职能部门」。 → 详细
02
搭 agent 要交的三种「税」：状态持久化、沙箱、可观测性
- 税一：checkpoint 与状态持久化。 agent 运行通常是长时间、有状态的，但基础设施本身是临时性的（ephemeral，进程说没就没）。一旦崩溃又没做持久化，消息历史、工具调用记录、「循环跑到哪一步了」全丢，session 没法恢复。 → 详细
- 退路是重启 session，但代价有三：原先用掉的 token 全白费；用户已经触发过一次、现在要重新等整个流程；副作用可能重复执行（agent 之前已经做过的带副作用操作，再跑一遍就翻倍）。 → 详细
- 税二：sandbox（沙箱，隔离的运行环境）基础设施。 我们跑的 agent 生成代码和第三方代码越来越多、全在自己的基础设施上，所以要用隔离沙箱防止它乱读环境密钥、乱访问网络、把共享主机搞挂。 → 详细
- 税三：可观测性（observability）。 要回答「到底在哪儿失败的」，通常得跨半打系统追日志和 trace。Jeff 的判断很干脆：以上这些「没有一项真正提升了 agent 的能力，它们全都是为了让 agent 能上场参与游戏而不得不交的税」。 → 详细
03
生态成熟了：云厂商出原语、框架兜复杂性，定义一个 agent 只剩五件事
- 变化来自两层：Cloudflare、Vercel、AWS 这些云基础设施厂商把一部分复杂性拿掉、做出一批原语（primitives，可直接复用的底层积木）；再配上 Flu、Vercel AI、Mastra 这些框架（转写里的专名按 ASR 原样保留），两者一起把大量复杂性消化掉，你可以专注于「真正能帮到你、你团队和你客户的核心逻辑」。 → 详细
- 他拿 Flu + Cloudflare 做了一个样例，「前面提到的那些东西基本都被兜住了」，第一次看文档时「被震到」：定义一个 agent 用不了多少代码。 → 详细
- 定义一个 agent 真正要做的只有五件事：A 选模型；B 指令（system prompt）；C 它能访问的工具；D skills（它能做的事）；E sandbox 的位置（在哪里跑）。 → 详细 → 详细
04
Demo：给 Linear 做的「工单补全 agent」
- 他亲手搭了一个 Linear（研发团队常用的工单/项目管理工具）issue 补全系统：给它一张 Linear 工单 + 代码仓库访问权限，它会拉工单、判断这是功能需求还是 bug、做代码搜索、把上下文交给 agent、最后给出一份下一步计划。 → 详细
- 演示用的工单是他一位「很厉害的工程师」同事大约一个月前提的真实 issue。 → 详细
05
翻车现场：agent 给出的「合理建议」其实几天前刚引发过一次故障
- 工单内容：Unblocked 自家的 agentic QA 流水线出现严重性能退化，首字符响应时间（time to first character）要 3–4 秒，正常应该是几百毫秒。agent 跑起来：拉工单 → 用 skills/工具拉代码、搜代码、查询 → 结果回传给 agent 推理 → 稍等一会儿，Linear 工单被自动更新了。 → 详细
- agent 的建议是「重新启用异步派发（async dispatch）」，理由也说得通——能让 QA 流水线在一台机器上并行跑更多任务。「听着很棒对吧？可惜，这是错的。」这个改动几天前刚引发过一次故障，一位支持工程师在工单出现之前就已经明确把它关掉了。 → 详细
- 错在哪？「我写的这个 agent 没有拿到全貌。」它缺了两样东西：① issue 之后那场 Slack 讨论——工程师们复盘了故障，哪里出了问题、怎么修的、下一步怎么办；② 由此产生的那张 postmortem（事后复盘）Linear 工单。总的来说，「它对问题的理解是很窄的」。 → 详细 → 详细
- 更要命的是部署形态：这是一个后台 agent，「它会在后台悄无声息地犯这个错，误导我的队友，也可能误导其他 agent」。Jeff 把这类问题概括为「散落在组织各处、不同系统里的知识和意图缺失」，并说它「会反反复复地冒出来」。 → 详细
06
为什么本地用 agent 不翻车？因为人就是那层上下文——你在给 agent 当保姆
- 他反问：大家都在本地用 agent，怎么不一定撞上这个问题？答案是「你——人，工程师——眼下就充当着那个上下文层」。和 agent 协作时，你在旁边提问、抓错、每一轮补上缺失的事实。人知道「代码为什么长这样、上次是什么坏了、我们决定怎么处理」。 → 详细
- 而 agent 只有右边那几样：指令、我们专门给它的工具和 skills、代码，以及眼前这张工单。人在回路里时，「我们在那儿负责纠偏和掌舵」，「说到底，我们就是在那儿给 agent 当保姆（babysit）」。 → 详细 → 详细
- 矛盾就在这里：agent 已经「极其容易部署」（前面 Flu + Cloudflare 的演示就是证据），一旦人不在回路里，这个问题就会越来越普遍，「缺失的上下文就成了失败的征兆」。「我们作为人所拥有的那些直觉和知识，得有东西来替代，得有东西把这副担子扛起来。」 → 详细
07
context engine 的定义与四个特征：按人给信息、化解冲突、守权限、交付「可行动的理解」
- 那个「扛担子的东西」就是 context engine（上下文引擎）。定义：「一个根据你是谁、什么对你重要，来提供与任务相关信息的系统」。 → 详细
- 四个特征：① 按人/按重要性给任务相关信息；② 化解多个数据集之间的冲突（Slack 里说 A、文档里写 B，谁算数）；③ 理解并严格遵守你或 agent 的访问规则，只给有权限且相关的信息；④ 最重要的——「交付一份 agent 可以直接据此行动的、经过综合的理解，而不是一堆还得 agent 自己去推理的文档列表」。 → 详细 → 详细
- 它怎么工作？先退一步问「agent 究竟需要什么」：很显然远不止源代码。「想想你每天工作需要的一切，不只是代码，还有做出决策的那些 Slack 讨论、写着各种最佳实践的文档。」 → 详细
08
Unblocked 的做法：连上一切 → 建组织模型 → 只给 agent 一个调和、排序、限权后的切片
- 「我们做的是把所有东西连起来：文档、代码、工单、对话。然后构建一个关于你的组织、你的系统的模型，把这些东西是如何协同运作的拼起来，并向你的 agent 开放。」 → 详细
- 关键不是「全给」，而是从这个模型出发，agent 只拿到数据中的一个切片，且是经过去重调和（reconciled）、排序（ranked）、并按你的权限限定范围（scoped）的。一句话概括：「零散的上下文进来，有根有据的上下文出去（Scattered context comes in, grounded context comes out）。」 → 详细
09
为什么不直接用 MCP？「MCP 擅长访问，但访问不等于理解」
- 显而易见的反问：接一个 Slack MCP、一个 Linear MCP、一个 GitHub MCP（MCP，让 agent 调外部工具/数据的标准接口），所有数据不就都能访问了吗？Jeff 的回答：「MCP is great at access, but access isn't understanding.」 → 详细 → 详细
- 纯 MCP 路线的三个代价：① MCP 把原始结果直接丢给 agent，你得指望 agent 自己决定该信什么；② 一堆无关数据把 agent 淹了，把上下文窗口塞满，「整体的上下文成本一路上涨」；③ 数据冲突的处理被留给了本地 agent——Linear MCP 和 Slack MCP 可能返回不一样的结果，「你就只能让 agent 当场随便拍个板（ad hoc）」。 → 详细
10
对照重跑：同一个文件、同一个引擎，接上 context engine 后建议反转
- 回到开头那张工单，「还是同一个文件、同一个引擎，但现在我们接上了 context agent」。流程几乎一样：先拉 Linear 工单，区别是这次调用了 Unblocked 的 context engine，去针对工单做调研、再把上下文交给 agent。 → 详细 → 详细
- context engine 找到了相关的那张 Linear 复盘工单、以及工程团队之间整场讨论所在的那段 Slack 对话，返回的是一份「理解」、以摘要形式交给 agent——「agent 不再需要自己从那些文档里去推理了」。 → 详细 → 详细
- 结果：agent 的建议「从『会搞坏、再引发一次故障』变成了『真正能防止下一次故障』」。 → 详细
11
上下文层能走得更远：写代码、code review、客户成功与销售，以及收尾金句
- 工单管理只是一个例子，上下文层能延伸到：写代码——在座各位都在用 Claude Code 或 Cortex（ASR 原样保留）写代码，用 context engine 给 agent 的计划「注水（hydrate）」，「在节省上下文和 token 方面效果非常显著」；code review——「能让 PR 看起来就像是被你团队里的专家审过一样，谁不喜欢这个呢」；把正确答案推给客户成功团队和销售。 → 详细 → 详细
- 总结：有很多场景你都会希望 agent 拥有你们组织的「制度性知识和部落知识（institutional and tribal knowledge）」。留给观众的一句话：「差距不在智能，而在上下文（The gap isn't intelligence, it's context）。」 → 详细
12
闪电问答 / 收尾
本期为 13 分钟大会演讲，无闪电问答；收尾即「差距不在智能，而在上下文」一句 + 致谢（见第十一节）。 → 详细 → 详细
13
联系方式
- Jeff 和 Unblocked 团队在大会 P16 展位；他提到次日还有更深入讲 context engine 工作原理的分会场（breakout session）。 → 详细