Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked

频道: AI Engineer
视频: https://www.youtube.com/watch?v=HvMyYLTfvhg
原文语言: en
统计: 共 19 轮 · Jeff 18

[0:13] Jeff

Hi all. Uh my name is Jeff. I'm a founding engineer at Unblock, and I'm here to talk to you about how building agents has actually gotten pretty easy. But unfortunately, they still get things confidently wrong. So, 6 months ago, it required a team's effort and basically a quarter to build out an agent. Um an agent is more than just models and tools. It's the models, the tools, and everything required to build out a production service. Here are some examples of the different systems that were necessary in order to build something out. Each one of these was basically its own company or at least a company function.

大家好。我叫 Jeff，是 Unblocked 的创始工程师。今天想跟大家聊的是：搭 agent 这件事其实已经变得相当容易了，但遗憾的是，它们还是会一本正经地犯错。六个月前，做出一个 agent 得靠一整个团队、差不多花一个季度。agent 可不只是模型加工具，它是模型、工具，再加上把它做成一个生产级服务所需要的一切。这里列了一些当时必须搭起来的各种系统，每一项基本上都够成立一家公司，或者至少是公司里的一个职能部门。

[0:54] Jeff

Not going to go through each one of these, but you know, a few that stood out to me. First one, checkpoint and state persistence. Agent runs, they're typically long-lived and stateful. Um unfortunately, uh infrastructure itself though, those that's ephemeral. Crashing without durability can actually lead to a lot of state loss. And that state kind of includes things like message history, tool calls, as well as, you know, where you are in the loop. Without these things, you can't resume the session. Uh one option is, you know, maybe you want to restart the session. Unfortunately, that's actually quite expensive as well.

我不会一个个过，但有几项让我印象特别深。第一个，checkpoint 和状态持久化。agent 的运行通常是长时间、有状态的，可惜基础设施本身却是临时性的。一旦崩溃又没有持久化，状态会丢掉一大片——消息历史、工具调用，还有你在循环里跑到哪一步了。没了这些，session 就没法恢复。一个办法是干脆重启 session，可惜那也相当昂贵。

[1:36] Jeff

Uh you lose out on all the tokens that you'd originally used, um as well as, you know, latency. Uh from a user experience standpoint, you've already triggered that session. Now you have to wait for the whole thing to go again. And lastly, side effects. Your agent might have performed some side effects, and now there's a chance of those doubling up. So, next thing, sandbox infrastructure, right? So, as we all know, we're running more and more agent-generated code as well as third-party code. This gets all run on your infrastructure, and due to that, there are some complexities. Uh because of that, we want to introduce isolated sandboxes, which help prevent uh unnecessary reads of environment secrets, unnecessary network access, you know, just in general, we don't want to take down the shared host.

你原先用掉的 token 全白费了，延迟也是。从用户体验角度讲，那个 session 你已经触发过了，现在又得等整个流程再跑一遍。最后还有副作用：agent 可能已经执行过一些带副作用的操作，这下有可能重复执行。接下来，sandbox 基础设施。大家都知道，我们跑的 agent 生成的代码和第三方代码越来越多，这些全都跑在你的基础设施上，随之而来就有不少复杂性。所以我们要引入隔离的 sandbox，防止不必要地读取环境密钥、不必要的网络访问——总之，别把共享主机搞挂了。

[2:29] Jeff

And then, observability. How do we answer the question, "Where did this fail?" Typically, this includes tracking logs and traces from across half a dozen systems. Everything I've mentioned here, none of this actually improves an agent's capabilities. They're all taxes one has to pay in order to get an agent out there to play the game. Thankfully, things have changed quite a bit. Um the whole ecosystem has matured quite a bit, and cloud infrastructure players such as Cloudflare, uh Vercel, AWS, they've gone and taken some of that complexity away and built primitives that these frameworks, Flu, Vercel E Maestra, with these together, you know, they've taken a lot of complexity away, and you can focus more on building the actual agent itself. The core logic that actually helps you and your team and your customers.

然后是可观测性。怎么回答「到底是在哪儿失败的」这个问题？通常得跨半打系统去追踪日志和 trace。我刚才提到的这些，没有一项真正提升了 agent 的能力，它们全都是为了把 agent 推上场、能参与这场游戏而不得不交的税。好在情况已经大不一样了。整个生态成熟了很多，Cloudflare、Vercel、AWS 这些云基础设施厂商把其中一部分复杂性拿掉了，做出了一批原语；再配上 Flu、Vercel AI、Mastra 这些框架，两者一起把大量复杂性消化掉了，你就可以更专注于构建 agent 本身——那些真正能帮到你、你的团队和你客户的核心逻辑。

[3:33] Jeff

So, here's an example of one. Uh I played around with Flu and Cloudflare, and as you can see on the left-hand side, you know, we basically handle everything as mentioned before. So, the primitives plus the framework lead to a situation where it's actually not that much code to define an agent. Uh one of the things I was shocked at when I first took a look at the documentation. To get in the details, all you really have to do when defining agent is A, deciding which model you want to use. B, the instructions or, you know, the system prompt. C, the tools that you want to ask the agent to have access to.

这是一个例子。我拿 Flu 和 Cloudflare 玩了一下，左边你可以看到，前面提到的那些东西基本都被兜住了。原语加框架，结果就是定义一个 agent 其实用不了多少代码。我第一次看文档的时候就被这点震到了。说具体点，定义一个 agent 你真正要做的就是：A，选用哪个模型；B，指令，也就是 system prompt；C，你想让 agent 能用的工具。

[4:12] Jeff

Skills, the things I can do. As well as the sandbox location, where things are being run. So, uh to give you an example of this, I've actually gone and built out a issue enrichment system specifically for Linear. So, what this does is, given a Linear ticket and access to your code repository, it'll go out, you know, fetch the Linear ticket, determine whether or not it's a feature or a bug. From there, it'll do some code searching, provide all that context to the agent, and then come up with a plan of next steps. On the left-hand side here, this is a issue that one of my colleagues, uh smart engineer, had posted, I think, a month ago.

skills，也就是它能做的事；还有 sandbox 的位置，也就是在哪里跑。举个具体例子，我专门给 Linear 做了一个 issue 补全系统。它的工作方式是：给它一张 Linear 工单和你代码仓库的访问权限，它会去拉这张 Linear 工单，判断这是个功能需求还是个 bug，然后做一些代码搜索，把所有这些上下文交给 agent，最后给出一份下一步的计划。左边这张 issue 是我一位同事——一位很厉害的工程师——大概一个月前提的。

[4:59] Jeff

Uh to summarize it, what had happened was, we had some pretty serious degradation in our agentic QA pipeline. Time to first character was taking 3 to 4 seconds when it should realistically be in the hundreds of milliseconds. So, let's see what happens when, you know, we put this through the system. So, as you'll see here, I've set up the agent to go fetch the agent. I've given it the skills and tools to actually go and fetch the code, search the code, and query against that. That's being passed back to the agent, which is doing some reasoning against that right now. And then, wait a little bit. At this point, we've updated the Linear issue ticket.

简单概括，当时发生的情况是我们的 agentic QA 流水线出现了相当严重的性能退化：首字符响应时间要 3 到 4 秒，而正常情况应该是几百毫秒。那我们看看把它丢进系统会怎样。你会看到，我设好了 agent 去拉取工单，给了它 skills 和工具去真正拉代码、搜代码、针对代码做查询。结果回传给 agent，它现在正在基于这些做推理。然后稍等一下——到这一步，Linear 的 issue 工单已经被更新了。

[5:42] Jeff

The recommendation here is to re-enable our async dispatch, which makes sense. It allows us to run a lot more of our QE pipeline in parallel on a single machine. Sounds great, right? Unfortunately, uh this is wrong. This had actually caused an outage a few days ago in one of our uh support engineers had explicitly disabled this uh before this ticket was uh shown. So, where did things go wrong? Why was the uh you know, why did I get it wrong? The agent I had written, it didn't have a full picture. It was missing the context from the Slack discussion that happened after the issue where the engineers came together, uh went through the actual outage, what went wrong, what was the fix, and the next steps.

它给的建议是重新启用我们的异步派发（async dispatch），这听起来合理，因为这样能让 QA 流水线的更多任务在一台机器上并行跑。听着很棒对吧？可惜，这是错的。这个改动几天前实际上引发过一次故障，我们一位支持工程师在这张工单出现之前就明确把它关掉了。那问题出在哪儿？为什么会搞错？我写的这个 agent 没有拿到全貌。它缺了 issue 之后那场 Slack 讨论的上下文——工程师们聚在一起复盘了那次故障，哪里出了问题、怎么修的、下一步怎么办。

[6:31] Jeff

It also was missing the postmortem uh linear ticket, which came as a result of that. In general, it had a narrow understanding of the problem. This concept of missing knowledge and intent that's stored across an organization and different systems is something that comes back and back again. And since this was deployed as a background agent, this is going to make that mistake silently in the background, misinforming both my teammates and potentially other agents. So, I guess the next question is, why don't we run into this locally? You know, we all use agents locally, we don't necessarily run into these issues.

它还缺了由此产生的那张事后复盘（postmortem）Linear 工单。总的来说，它对问题的理解是很窄的。这种「散落在组织各处、不同系统里的知识和意图缺失」的问题，会反反复复地冒出来。而且因为它是作为后台 agent 部署的，它会在后台悄无声息地犯这个错，误导我的队友，也可能误导其他 agent。那么下一个问题自然是：为什么我们在本地用的时候没撞上这个问题？大家都在本地用 agent，却不一定会碰到这些麻烦。

[7:08] Jeff

Well, you, the human, the engineers, we currently act as that context layer. When working with an agent, you know, you're there to ask questions, catch any errors, and supply the missing facts on every single turn. A person knew why the code is the way it is, what broke last time, and what we've decided to do about it. The agent, though, it only has what's on the right-hand side, right? It has instructions, the tools and skills we specifically gave it, the code, as well as the ticket in front of it. When an agent is in the loop, well, sorry, when a human is in the loop with the agent, we're there to catch the steer.

因为你——人，工程师——眼下就充当着那个上下文层。跟 agent 协作的时候，你在旁边提问、抓错、在每一轮补上缺失的事实。人知道代码为什么长这样、上次是什么坏了、以及我们决定怎么处理。而 agent 只有右边这些：指令、我们专门给它的工具和 skills、代码，以及眼前这张工单。当 agent 在回路里——不好意思，当人和 agent 一起在回路里的时候，我们在那儿负责纠偏和掌舵。

[7:47] Jeff

Ultimately, we're there to babysit the agent. But as agents have gotten trivially easy to deploy as I showed earlier with Flu Cloudflare, the without the human in the loop, this issue becomes more and more prevalent. This missing context becomes a sign of failure. You know, all that intuition and knowledge that we've had as humans needs to be replaced. Something needs to carry the load. So, that thing, that's a context engine. A context engine is a system that provides task-relevant information based on who you are and what matters. It also resolves all the conflicts across multiple data sets.

说到底，我们就是在那儿给 agent 当保姆。但正如我刚才用 Flu 加 Cloudflare 演示的，agent 已经变得极其容易部署，一旦人不在回路里，这个问题就会越来越普遍。缺失的上下文就成了失败的征兆。我们作为人所拥有的那些直觉和知识，得有东西来替代，得有东西把这副担子扛起来。这个东西，就是 context engine（上下文引擎）。context engine 是一个系统，它根据你是谁、什么对你重要，来提供与任务相关的信息；它还会把多个数据集之间的冲突都化解掉。

[8:29] Jeff

It understands your access rules or the agent's access rules and only uh respects that and only provides information that's relevant. And most importantly, it delivers a synthesized understanding that an agent can act on, not just a list of documents that I have to reason upon itself. So, how does this context engine work? Well, let's take a step back. What does an agent actually need? An agent needs Clearly, it needs context outside of just your source code. Think about everything that you need to work day-to-day. It's not just the code. It's, you know, the Slack discussions where decisions are made, the documentation where we show all the best practices.

它理解你的访问规则——或者说 agent 的访问规则——并严格遵守，只提供相关的信息。最重要的是，它交付的是一份 agent 可以直接据此行动的、经过综合的理解，而不是一堆还得 agent 自己去推理的文档列表。那这个 context engine 是怎么工作的？我们先退一步：agent 究竟需要什么？很显然，它需要的上下文远不止源代码。想想你每天工作需要的一切，不只是代码，还有做出决策的那些 Slack 讨论、写着各种最佳实践的文档。

[9:13] Jeff

All that is important to your day-to-day process, and that's true for your agent as well. So, what we do here is we connect everything. The docs, code, tickets, conversations. We then build a model of your organization, of your system. And we piece how all these things work together and make it generally available to your agents. From that model, the agents are only provided a a of that data, which has been reconciled, ranked, and scoped to your permissions. Scattered context comes in, grounded context comes out. The obvious next question is, why can't we just do this with MCP, right? You could connect a Slack MCP, a Linear MCP, a GitHub MCP, and with that, all that data is accessible.

这些对你的日常流程都很重要，对你的 agent 同样如此。所以我们做的是把所有东西连起来：文档、代码、工单、对话。然后我们构建一个关于你的组织、你的系统的模型，把这些东西是如何协同运作的拼起来，并向你的 agent 开放。从这个模型出发，agent 只会拿到数据中的一个切片，而且是经过去重调和、排序、并按你的权限限定范围的。零散的上下文进来，有根有据的上下文出去。接下来显而易见的问题是：为什么不直接用 MCP 做这件事？你可以接一个 Slack MCP、一个 Linear MCP、一个 GitHub MCP，这样所有数据就都能访问到了。

[9:57] Jeff

MCP is great at access, but access isn't understanding. An MCP hands the agent the raw results, and you know, you're now dependent on that agent to actually decide what to believe in. You end up flooding the agent with irrelevant data, filling up the context window, and you know, overall context costs just go up. It also leaves the local agent to handle conflicts in data. You know, your Linear MCP and your Slack MCP may come back with different results. You're just leaving the agent to make that decision somewhat ad hoc at the moment. So, back to the original problem I had earlier. This is the same file, same engine, but now we've connected the context agent.

MCP 擅长的是访问，但访问不等于理解。MCP 把原始结果直接丢给 agent，然后你就得指望那个 agent 自己去决定该信什么。结果就是一堆无关数据把 agent 淹了，把上下文窗口塞满，整体的上下文成本一路上涨。它还把数据冲突的处理留给了本地的 agent——你的 Linear MCP 和 Slack MCP 可能返回不一样的结果，你就只能让 agent 当场随便拍个板。好，回到我刚才那个问题。还是同一个文件、同一个引擎，但现在我们接上了 context agent。

[10:40] Jeff

Uh what we do here is is we're currently prompting Unblock to do some research on the ticket and provide that context to the agent. So, let's see that in action. Sorry about that. So, here we go. Uh we're doing the very similar thing. We're fetching the Linear ticket. But, you'll notice here that we're actually calling the Unblock context engine. And what's done here is actually it's found the relevant Linear postmortem, as well as a Slack conversation where we've had the entire discussion between the engineering teams. And as part of that, we've returned a understanding, and that's now been provided to the agent as a summary.

我们这里做的是让 Unblocked 去针对这张工单做一些调研，再把那份上下文交给 agent。来看实际效果。抱歉，稍等。好，开始了。我们做的事情非常相似：先拉取 Linear 工单，但你会注意到，这次我们实际上调用了 Unblocked 的 context engine。它做的事情是找到了相关的那张 Linear 复盘工单，以及一段 Slack 对话——工程团队之间的整场讨论都在里面。基于这些，我们返回了一份理解，现在以摘要的形式交给了 agent。

[11:26] Jeff

So, the agent no longer has to actually reason from those documents. Uh at this point, you'll notice here the agent now has been updated. Uh the recommendation has gone from breaking and causing another issue to actually preventing a another outage. So, the example I've shown here is issue ticket management, but this context layer can actually go a lot further. Uh for example, coding. Everyone here does uh coding with uh cloud code or cortex. Using an Unblocked context engine to actually hydrate the agent plan goes a long way in terms of saving context and tokens. Uh code review. It makes the PRs look as if they've been reviewed by an expert on your team. Who doesn't like that?

所以 agent 不再需要自己从那些文档里去推理了。到这一步，你会看到 agent 的结论已经更新了：建议从「会搞坏、再引发一次故障」变成了「真正能防止下一次故障」。我这里展示的例子是 issue 工单管理，但这个上下文层实际上能走得远得多。比如写代码，在座各位都在用 Claude Code 或者 Cortex 写代码，用 Unblocked 的 context engine 去给 agent 的计划「注水」，在节省上下文和 token 方面效果非常显著。还有 code review，它能让 PR 看起来就像是被你团队里的专家审过一样——谁不喜欢这个呢？

[12:21] Jeff

As well as surfacing the correct answers to your customer success team as well as sales. In general, there are many instances where you might want an agent to have institutional and tribal knowledge of your organization. Just want to leave you on this. I think this quote encapsulates what we're trying to solve at Unblocked. The gap isn't intelligence, it's context. So, thank you. Uh I'll be at booth P16 along with the rest of my team if you guys have any questions. There will be additional breakout sessions later tomorrow, I believe, that goes a lot more in depth about actually how the context engine works and you know, how you can benefit from that.

此外还能把正确的答案推给你的客户成功团队和销售团队。总的来说，有很多场景你都会希望 agent 拥有你们组织的制度性知识和「部落知识」。最后留给大家这句话，我觉得它概括了我们在 Unblocked 想解决的问题：差距不在智能，而在上下文。谢谢大家。我和团队其他人会在 P16 展位，有问题欢迎来找我们。我记得明天晚些时候还有分会场，会更深入地讲 context engine 具体是怎么工作的，以及你能从中怎么受益。

[13:03] Jeff

Cheers.

谢谢。

[13:04]

[applause]

（掌声）