跨国深谈← 返回←Navan 架构师谈生产环境智能体：从运行时到护栏的实战分层

Navan 架构师谈生产环境智能体：从运行时到护栏的实战分层

关联

人物 Roberto Milev · Uday Kanagala

公司 Navan · AWS

概念 智能体 · 智能体运行时 · 记忆 · 上下文管理 · 技能 · 渐进式披露 · 可观测性 · hooks · 轨迹数据 · 护栏与授权 · 人在回路 · MCP · A2A 协议 · RAG

如果你在 AI 智能体(能自己规划步骤、调用工具完成任务的 AI 系统)上踩过坑，这一集会很有共鸣。说话的是 Navan 的首席架构师 Roberto Milev 和架构团队的 Uday——Navan 是一家差旅和费用管理公司，他们已经在生产环境跑着大量智能体、每天消耗大量 token。

开场 Roberto 先给了一个类比：当年大家一窝蜂上微服务，才慢慢学会了容器编排、服务网格；今天也一样——如果你连一个结构良好的单体都建不好，就别去建微服务；如果你连一个单一的智能体循环都建不好，就别去搭多智能体编排系统。围绕「怎么在生产环境可靠跑智能体」，一套参考架构正在浮现。

运行时：智能体天生带状态

传统微服务的整套方法论建立在「无状态扩展」上，而智能体恰恰相反：它们需要持久会话、需要隔离、生命周期也和传统 API 服务完全不同。云厂商纷纷进场填补这个空白——AWS、GCP、Azure 都有自己的智能体运行时产品。Navan 全部跑在 AWS 上，重度使用 AWS 的 agent core 运行时，但会话持久化和状态恢复(进程重启后把会话状态还原回来)是官方没覆盖的空白，他们自己构建了。

记忆与上下文：把「技能」当作上下文单元

记忆层从 RAG(检索增强生成，即把相关资料检索出来塞给模型)起步，行业已经形成一条「摄取 → 提取 → 整合 → 检索」的自动化流水线，记忆从短期对话记忆逐步积累为长期记忆，还有关于哪些实例成功、哪些失败的情景记忆。Navan 用 AWS 的 agent core 记忆，但按自己的用例做了定制。

上下文管理是更难的题目：上下文窗口越来越大，但上下文永远不够——而太多上下文智能体又会失去焦点。他们找到的有效做法是：把技能(skill)当作上下文的单元。

一个技能既包含某个领域或任务的指令和设置，也包含工具执行那部分智能体逻辑；技能是可插拔的工作单元，能独立测试、能复用，上下文从技能动态组合出来。再借助「渐进式披露」——先加载有限范围的上下文，后续再按元数据逐步展开。

可观测性：别再翻日志，用 hooks 拦截

Uday 接棒后先问了全场一个问题：谁构建过跑 30 步、中途失败、还能快速搞清楚为什么失败的智能体？传统微服务靠查日志，但智能体输出大量思考内容，多到没法消化。

正确姿势是用 Claude 的 hooks(在工具调用前后、会话前后等时点拦截智能体行为的机制)——在每次工具调用前后拦截，看它调了什么工具、做了什么决策，然后决定是阻止、放行，还是记录指标。Navan 用供应商 Braintrust 发出 OTL 追踪，通过 span 定位智能体卡在哪一步。

追踪里他们重点捕获几个信号：智能体当前的目标、操作背后的原因、信念状态、工具调用，以及每个决策的置信度分数——这个选择是由多条路径支撑，还是单纯推断出来的。如果是推断出来的答案，就安排人类在环来引导和调整。

测试非确定性系统：轨迹评估

智能体是非确定性的——同样一个目标，它每次自行制定的步骤都不一样，「改一处、坏一处」是常态。无法画出确定性的执行图，Navan 转而依赖轨迹(trajectory)评估：不看它每步做对了什么，而是算它从起点到目标走了多远、偏离了多少，以此评估效率与完整性;再结合前面的推断信号，把疑似回归的情况循环回来、分类、修复。

护栏与授权：智能体代表我下单，算谁下的单？

大量信息被输进模型，敏感信息可能在我们不知情的情况下进入其中，治理层必须挡在前面。更微妙的是授权：「只要机票比 200 美元便宜就帮我订」——智能体代表你完成了购买，这次购买到底是你做的，还是「智能体版的你」做的？

传统上授权对象是用户或服务账号，现在智能体既可以代表用户行事、也可以自己作为账号，界线正在模糊，需要细粒度的授权决策和策略层。Navan 的做法是在每次工具调用前后都挂护栏，做检查、拦截和决策。

单智能体还是多智能体？

回到开场的类比：单智能体都没做好，别急着上多智能体。Navan 的架构是单一主智能体 + 子技能：一个主智能体渐进式加载技能，自己判断什么该进上下文，在用例中导航，内部再分出子智能体。多智能体的合理场景主要是组织边界：大规模组织里各团队互不沟通，两边各挂一个智能体，用 A2A 协议(智能体对智能体通信的协议)在技能层面建立契约，协议本身就是团队之间的边界。

成熟度盘点：什么解决了，什么还在挣扎

Roberto 最后盘点整个栈：运行时基本解决了；编排和扩展靠暴力堆 LLM 也不是问题；记忆会随着前沿模型和实践进步逐步覆盖大多数用例；MCP 已成事实协议，工具调用人人都支持，行业在趋同，MCP 本身也在演进(正在变得无状态)。

还在挣扎的地方：可观测性——业界在向 OTL 推进，但 OTL 真的适合智能体调用吗？能跑，但未知还很多；测试依然很难，不过他们已经能在系统不可靠的情况下给客户高质量体验；成本是最大的痛点之一——很难预测、很难管理、很难设护栏，部分原因是大 AI 厂商的利益就是让大家多花 token;重放与调试也很难，但他认为这会被解决——因为可以用智能体来克服调试智能体的认知过载。

标准由社区形成中，A2A 还年轻、由某些厂商推动，但随着时间推移会到位。他的结论：「我们知道自己需要什么，接下来就看我们自己去把它构建出来了。」

本集带走

• 先做好单智能体循环，再谈多智能体编排——Navan 的架构就是单一主智能体 + 子技能，靠渐进式加载技能来导航，不过度工程化。
• 把「技能」当上下文单元：指令 + 工具执行打包成可插拔、可独立测试、可复用的工作单元，上下文从技能动态组合，避免「上下文太多反而失焦」。
• 别靠翻日志调试智能体：用 hooks 在工具调用前后拦截，发出含目标、推理原因、置信度的 OTL 追踪，定位卡点。
• 非确定性系统的测试用轨迹评估：不算每步对错，算从起点到目标的完成度与偏移，推断型答案配人类在环。
• 护栏挂在每次工具调用前后：智能体代表用户行事让授权界线模糊，需要细粒度策略层，也防敏感信息悄悄进模型。
• 成本是当前最未解的一层：难预测、难管理、难回退，要用更便宜的模型分担任务也得靠自己搭机制。

如果你连一个单一的智能体循环都建不好，为什么还要去构建一个多智能体编排系统呢？
if you can’t build a single agentic loop, why go in and try to build a multi-agent orchestrated system?
—— Roberto Milev · [01:28]

上下文窗口越来越大，但上下文永远不够。
Context windows are growing bigger, but there’s never enough context.
—— Roberto Milev · [05:20]

所以是我做的这次购买，还是「智能体版的我」代表我做的？
So is it me making this purchase or is it agent me making on behalf of me?
—— Uday Kanagala · [13:12]

这一切在很大程度上是由那些大型 AI 厂商驱动的，我认为他们的利益就在于让我们所有人都花更多的 token。
This is all driven by kind of the big AI vendors who I think their interest is for us all to spend more tokens.
—— Roberto Milev · [18:12]

这也是会被解决的问题，因为我们现在可以用智能体来克服「试图调试智能体行为」所带来的认知过载。
This is also something that is gonna be solved because we can now use agents to get over the cognitive overload of trying to debug what they do.
—— Roberto Milev · [18:30]