代理基础设施和新后端

spinny:~/writing $ less agentic-infrastructure-stack.md

1 
2我们经常谈论代理框架。 LangGraph、CrewAI、AutoGen、各种 SDK、循环、工具调用、内存、规划器、评论家、主管。老天爷，所有有用的话。但是，我对实际使用的代理了解得越多，我就越觉得有趣的部分已经移到了框架级别以下。
3 
4问题不再只是：我应该使用哪个库来让步骤模型思考？
5 
6真正的问题是：当这个特工不再是演示时，他住在哪里？
7 
8因为一个严肃的代理并不是一个调用模型并返回文本的函数。这是一个小型分布式系统。它必须读取上下文、使用工具、执行代码、触摸文件、记住决策、请求许可、很好地失败、重新启动、留下日志、不消耗预算、不变成生产存储库中的推土机。
9 
10框架是方向盘。基础设施包括道路、刹车、车库、保险和知道钥匙在哪里的人。
11 
12## 因为现在有很多关于它的讨论
13 
142023 年和 2024 年的对话非常以模型为中心。哪个法学硕士？有多少上下文？它要多少钱？他的编程水平如何？
15 
162025 年和 2026 年，话题发生了转变。这些模型足以完成实际工作，但这就是为什么无聊的部分变得可见：运行时、安全性、连接器、身份、可观察性、代码执行、部署、回滚。
17 
18这是从魔法到工程的自然过渡。
19 
20当代理只需要生成响应时，聊天就足够了。当您需要打开拉取请求、查询数据库、调用 CRM、启动作业、导航站点、阅读 Slack、编译代码和更新文档时，您需要一个围绕它的操作系统。
21 
22不是字面意义上的。从组织意义上来说。
23 
24## 第一部分：代理可以持续的运行时
25 
26代理人通常按步骤进行工作。查看状态，选择操作，使用工具，观察结果，更新计划，重复。
27 
28如果此循环存在于单个 HTTP 请求中，您就会立即遇到问题。有些动作很慢。有些等待人工输入。有些失败了，必须重试。有些必须在部署或超时后幸存下来。
29 
30这就是持久工作流程、队列、作业背景和状态机发挥作用的地方。他们并不光鲜亮丽，但他们是在演示中看起来很聪明的代理人和你可以一边喝咖啡一边工作的代理人之间的区别。
31 
32对我来说，代理运行时必须回答非常具体的问题：
33 
34- 我在哪里保存一个步骤与另一个步骤之间的状态？
35- 如果进程中途终止会发生什么？
36- 我可以暂停并请求批准吗？
37- 我可以重播一次跑步来了解他为什么做出这样的选择吗？
38- 我可以限制持续时间、内存、工具和成本吗？
39 
40Vercel 正在通过 AI SDK、功能、工作流程和用于在 Web 应用程序中构建代理的工具，大力推动这一领域的发展。但重点不只是维塞尔。关键是代理需要一个可操作的家，而不是单个端点。
41 
42## 第二块：沙箱，因为代理必须能够在不破坏的情况下弄脏
43 
44一旦代理编写代码或执行命令，就需要沙箱。
45 
46这看起来像是一个技术词，但这个想法是国内的：你给他一个工作台。它可以打开文件、安装依赖项、运行测试、进行实验、生成输出。如果他弄错了，你就已经控制住了损失。如果有效，就推广结果。
47 
48代理沙箱应该具有一些属性：
49 
50- 隔离的文件系统；
51- CPU、内存和时间限制；
52- 受控网络；
53- 仅在需要时安装秘密；
54- 完整的日志；
55- 出口文物的可能性；
56- 必要时，在运行之间进行干净的重置。
57 
58Vercel Sandbox 正是朝着这个方向发展：运行代码、安装依赖项、处理文件和生成工件的隔离环境，而无需在主应用程序运行时运行所有内容。
59 
60这件事比看起来更重要。许多代理原型直接从模型跳转到真实系统。该模型可以调用工具。工具可以做事。这一切看起来都很优雅，直到第一个错误的命令、第一个依赖项安装在错误的位置、第一个令牌最终出现在日志中。
61 
62沙盒是成人的说法：继续，但在这里。
63 
64## 第三块：MCP和连接器问题
65 
66模型上下文协议已经成为生态系统中最有趣的部分之一，因为它试图标准化一些否则很快就会变得难以管理的东西：模型如何发现和使用外部工具。
67 
68如果没有标准，每次集成都是一座小岛。 GitHub 的连接器以一种方式完成，Slack 的连接器以另一种方式完成，一种用于具有不同语义的数据库，一种用于浏览器自动化，看起来没什么。
69 
70MCP提出了客户端和服务器之间的通用语言：工具、资源、提示、授权、传输、发现。它并没有神奇地解决治理和安全问题，但它提供了一种语法。
71 
72语法很重要。当代理可以连接到许多工具时，问题不仅仅是“他能做到吗？”。问题是“他是否明白自己能做什么、有什么限制、代表谁、留下什么痕迹？”。
73 
74对我来说，MCP 并不是炒作，因为它“进行工具调用”。我们已经这样做了。这是炒作，因为它将重心从单一集成转移到工具的操作目录。
75 
76在良好的代理架构中，MCP 成为一种配线架：
77 
78- GitHub 上的代码和问题；
79- Slack 用于对话上下文；
80- 用于计划工作的 Linear 或 Jira；
81- 用于分析的只读数据库；
82- 为外部站点控制的浏览器或抓取工具；
83- 文件存储；
84- 隔离的执行环境；
85- 具有严格权限的内部系统。
86 
87棘手的部分是，无策略的工具目录只是一种更优雅的方式来制造混乱。
88 
89## 第四块：身份与权限
90 
91这是许多演示视而不见的领域。
92 
93代理人代表某人行事。所以必须清楚行动的主体是谁。
94 
95是否使用用户权限？服务帐户的？工作区？您有临时或永久访问权限吗？您可以阅读所有内容还是只阅读一些资源？你会写吗？可以取消吗？他可以给真人发短信吗？
96 
97如果你不能很好地回答这些问题，迟早你会创造出一个拿着房子钥匙的助手，但不记得是谁给他的。
98 
99我喜欢的经验法则是：智能体必须能够比人类做得更少，而不是比人类做得更多。当他必须做一些风险更大的事情时，他必须停下来询问。
100 
101这意味着 OAuth、令牌范围、秘密管理、审核日志、工具策略、白名单、批准步骤。不是很浪漫的事情。必要的东西。
102 
103## 第五块：内存和上下文，但不积累垃圾
104 
105特工需要内存，但当内存变成阁楼时就会很危险。
106 
107记忆至少分为三种类型：
108 
109- 运行内存：本次执行中发生了什么；
110- 项目记忆：约定、决定、约束；
111- 个人或团队记忆：偏好、语气、仪式、流程。
112 
113将所有内容都放在提示中是捷径。它一直有效，直到不再有效为止。必须注意有用的内存：索引、更新、过期、验证、可引用。
114 
115An agent who remembers badly is worse than an agent who doesn't remember.因为他说话充满自信。
116 
117因此，基础设施必须包括检索、指令文件、知识库、需要时的嵌入以及清理。我们需要一种记忆文化：什么进入，谁批准它，当它衰退时，我如何纠正它。
118 
119## 第六块：可观察性、评估和重放
120 
121如果代理犯了错误，“调用模型”日志是不够的。
122 
123你想看看路线。他收到了什么背景信息？有哪些可用的工具？您选择了哪个工具？有何论据？你得到什么回应？花了多少钱？哪里卡住了？人类认可什么吗？错误是模型、工具、提示、数据还是权限错误？
124 
125这里的代理更像是分布式系统而不是聊天机器人。
126 
127You need readable traces, not just text logs.您需要能够重播跑步。有必要在已知任务上比较同一代理的两个版本。我们需要衡量回归：它不仅“回答得更好”，而且“在不触及未经请求的文件的情况下关闭正确的票证”。
128 
129代理评估比文本评估更困难，因为它们包括操作。比较预期的字符串是不够的。你必须考虑序列、副作用、人工制品的质量、时间、成本、人工干预的数量。
130 
131有趣的是，我们总是回到那里：软件工程。测试、环境、跟踪、回滚。除了代码现在还决定下一步做什么。
132 
133## 第七块：人机界面
134 
135代理不必只生活在聊天中。
136 
137有些代理商需要董事会。其他页面包含状态和日志。其他人有一个“批准”按钮。更多内嵌评论。还有一些 CLI。
138 
139UI 改变行为。如果控制代理的唯一方法是编写长消息，则用户会给代理发出模糊的指示。然而，如果他看到计划、差异、来源、风险和下一步行动，他就可以精确干预。
140 
141良好的代理基础设施包括控制面：
142 
143- 当前状态；
144- 可编辑的计划；
145- 制作的文物；
146- 差异；
147- 批准请求；
148- 年表；
149- 停止按钮；
150- 重试按钮；
151- 可见的权限。
152 
153这看起来微不足道，但事实并非如此。 “令人毛骨悚然的人工智能”和“可靠的助手”之间的区别通常只是后者向你展示了它的手脚。
154 
155## 心理堆栈
156 
157如果我今天画它，最小的代理堆栈将是这样的：
158 
1591.模型：推理、生成、工具调用、必要时多模态。2.编排：循环、步骤、规划器、策略、人机循环。3. 持久运行时：工作流、队列、重试、暂停、恢复。4. 沙箱：代码执行、隔离文件系统、限制、工件。5.工具层：MCP、内部API、浏览器、数据库、存储库。6. 身份层：OAuth、范围、秘密、审计、策略。7. 内存层：项目上下文、检索、指令、过期。8. 可观察性：跟踪、重放、评估、成本和质量指标。9. 产品表面：足够时聊天，需要时仪表板，重要时进行审查。
160 
161代理框架主要涵盖了第2点和第1点的一部分。剩下的就是真正的工作了。
162 
163## 我在实践中会做什么
164 
165如果一个团队告诉我“我们想要生产中的代理”，我不会从十个代理开始。
166 
167I would start with a small, repetitive and observable workflow.例如：开放维护 PR、更新已关闭问题的文档、准备每周审查、分类重复错误、为受影响的文件生成测试。
168 
169然后我会设定非常明确的限制：
170 
171- 没有分支或沙箱就不能写作；
172- 提示中没有秘密；
173- 列入白名单的工具；
174- 人类对外部行为的批准；
175- 强制日志和跟踪；
176- 每次运行的预算；
177- 输出始终可检查。
178 
179只有这样我才会扩展。
180 
181智能体不会仅仅因为模型出错而失败。它们之所以失败，是因为我们将它们置于模糊的环境中，具有令人困惑的权限和戏剧性的期望。
182 
183## 我的阅读
184 
185代理基础设施在最好的方面是无聊的。
186 
187这并不是演示中让你鼓掌的部分。这是让您在周一早上实际使用演示的部分，涉及真实的人员、真实的数据和真实的结果。
188 
189代理人的未来不仅仅取决于谁拥有最好的榜样。 It will be decided by whoever builds the best place in which to make him work: isolated when he experiments, connected when needed, always observable, authorized with criteria and humble enough to stop when he doesn't know.
190 
191这就是代理不再是玩具而是成为基础设施的地方。
192 
193## 来源
194 
195- [Vercel：如何使用 Vercel 和 AI SDK 构建 AI 代理](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
196- [Vercel 文档：沙箱](https://vercel.com/docs/sandbox)
197- [Vercel 文档：使用沙箱](https://vercel.com/docs/sandbox/working-with-sandbox)
198- [Vercel 文档：MCP](https://vercel.com/docs/mcp)
199- [模型上下文协议：规范](https://modelcontextprotocol.io/specification)
200- [OpenAI：构建代理的新工具](https://openai.com/index/new-tools-for-building-agents/)
201- [Cloudflare 博客：Cloudflare 上的代理](https://blog.cloudflare.com/agents-on-cloudflare/)
202

:代理基础设施和新后端lines 1-202 (END) — press q to close

2我们经常谈论代理框架。 LangGraph、CrewAI、AutoGen、各种 SDK、循环、工具调用、内存、规划器、评论家、主管。老天爷，所有有用的话。但是，我对实际使用的代理了解得越多，我就越觉得有趣的部分已经移到了框架级别以下。

4问题不再只是：我应该使用哪个库来让步骤模型思考？

6真正的问题是：当这个特工不再是演示时，他住在哪里？

8因为一个严肃的代理并不是一个调用模型并返回文本的函数。这是一个小型分布式系统。它必须读取上下文、使用工具、执行代码、触摸文件、记住决策、请求许可、很好地失败、重新启动、留下日志、不消耗预算、不变成生产存储库中的推土机。

10框架是方向盘。基础设施包括道路、刹车、车库、保险和知道钥匙在哪里的人。

12## 因为现在有很多关于它的讨论

142023 年和 2024 年的对话非常以模型为中心。哪个法学硕士？有多少上下文？它要多少钱？他的编程水平如何？

162025 年和 2026 年，话题发生了转变。这些模型足以完成实际工作，但这就是为什么无聊的部分变得可见：运行时、安全性、连接器、身份、可观察性、代码执行、部署、回滚。

18这是从魔法到工程的自然过渡。

20当代理只需要生成响应时，聊天就足够了。当您需要打开拉取请求、查询数据库、调用 CRM、启动作业、导航站点、阅读 Slack、编译代码和更新文档时，您需要一个围绕它的操作系统。

22不是字面意义上的。从组织意义上来说。

24## 第一部分：代理可以持续的运行时

26代理人通常按步骤进行工作。查看状态，选择操作，使用工具，观察结果，更新计划，重复。

28如果此循环存在于单个 HTTP 请求中，您就会立即遇到问题。有些动作很慢。有些等待人工输入。有些失败了，必须重试。有些必须在部署或超时后幸存下来。

30这就是持久工作流程、队列、作业背景和状态机发挥作用的地方。他们并不光鲜亮丽，但他们是在演示中看起来很聪明的代理人和你可以一边喝咖啡一边工作的代理人之间的区别。

32对我来说，代理运行时必须回答非常具体的问题：

34- 我在哪里保存一个步骤与另一个步骤之间的状态？

35- 如果进程中途终止会发生什么？

36- 我可以暂停并请求批准吗？

37- 我可以重播一次跑步来了解他为什么做出这样的选择吗？

38- 我可以限制持续时间、内存、工具和成本吗？

40Vercel 正在通过 AI SDK、功能、工作流程和用于在 Web 应用程序中构建代理的工具，大力推动这一领域的发展。但重点不只是维塞尔。关键是代理需要一个可操作的家，而不是单个端点。

42## 第二块：沙箱，因为代理必须能够在不破坏的情况下弄脏

44一旦代理编写代码或执行命令，就需要沙箱。

46这看起来像是一个技术词，但这个想法是国内的：你给他一个工作台。它可以打开文件、安装依赖项、运行测试、进行实验、生成输出。如果他弄错了，你就已经控制住了损失。如果有效，就推广结果。

48代理沙箱应该具有一些属性：

50- 隔离的文件系统；

51- CPU、内存和时间限制；

52- 受控网络；

53- 仅在需要时安装秘密；

54- 完整的日志；

55- 出口文物的可能性；

56- 必要时，在运行之间进行干净的重置。

58Vercel Sandbox 正是朝着这个方向发展：运行代码、安装依赖项、处理文件和生成工件的隔离环境，而无需在主应用程序运行时运行所有内容。

60这件事比看起来更重要。许多代理原型直接从模型跳转到真实系统。该模型可以调用工具。工具可以做事。这一切看起来都很优雅，直到第一个错误的命令、第一个依赖项安装在错误的位置、第一个令牌最终出现在日志中。

62沙盒是成人的说法：继续，但在这里。

64## 第三块：MCP和连接器问题

66模型上下文协议已经成为生态系统中最有趣的部分之一，因为它试图标准化一些否则很快就会变得难以管理的东西：模型如何发现和使用外部工具。

68如果没有标准，每次集成都是一座小岛。 GitHub 的连接器以一种方式完成，Slack 的连接器以另一种方式完成，一种用于具有不同语义的数据库，一种用于浏览器自动化，看起来没什么。

70MCP提出了客户端和服务器之间的通用语言：工具、资源、提示、授权、传输、发现。它并没有神奇地解决治理和安全问题，但它提供了一种语法。

72语法很重要。当代理可以连接到许多工具时，问题不仅仅是“他能做到吗？”。问题是“他是否明白自己能做什么、有什么限制、代表谁、留下什么痕迹？”。

74对我来说，MCP 并不是炒作，因为它“进行工具调用”。我们已经这样做了。这是炒作，因为它将重心从单一集成转移到工具的操作目录。

76在良好的代理架构中，MCP 成为一种配线架：

78- GitHub 上的代码和问题；

79- Slack 用于对话上下文；

80- 用于计划工作的 Linear 或 Jira；

81- 用于分析的只读数据库；

82- 为外部站点控制的浏览器或抓取工具；

83- 文件存储；

84- 隔离的执行环境；

85- 具有严格权限的内部系统。

87棘手的部分是，无策略的工具目录只是一种更优雅的方式来制造混乱。

89## 第四块：身份与权限

91这是许多演示视而不见的领域。

93代理人代表某人行事。所以必须清楚行动的主体是谁。

95是否使用用户权限？服务帐户的？工作区？您有临时或永久访问权限吗？您可以阅读所有内容还是只阅读一些资源？你会写吗？可以取消吗？他可以给真人发短信吗？

97如果你不能很好地回答这些问题，迟早你会创造出一个拿着房子钥匙的助手，但不记得是谁给他的。

99我喜欢的经验法则是：智能体必须能够比人类做得更少，而不是比人类做得更多。当他必须做一些风险更大的事情时，他必须停下来询问。

100

101这意味着 OAuth、令牌范围、秘密管理、审核日志、工具策略、白名单、批准步骤。不是很浪漫的事情。必要的东西。

102

103## 第五块：内存和上下文，但不积累垃圾

104

105特工需要内存，但当内存变成阁楼时就会很危险。

106

107记忆至少分为三种类型：

108

109- 运行内存：本次执行中发生了什么；

110- 项目记忆：约定、决定、约束；

111- 个人或团队记忆：偏好、语气、仪式、流程。

112

113将所有内容都放在提示中是捷径。它一直有效，直到不再有效为止。必须注意有用的内存：索引、更新、过期、验证、可引用。

114

115An agent who remembers badly is worse than an agent who doesn't remember.因为他说话充满自信。

116

117因此，基础设施必须包括检索、指令文件、知识库、需要时的嵌入以及清理。我们需要一种记忆文化：什么进入，谁批准它，当它衰退时，我如何纠正它。

118

119## 第六块：可观察性、评估和重放

120

121如果代理犯了错误，“调用模型”日志是不够的。

122

123你想看看路线。他收到了什么背景信息？有哪些可用的工具？您选择了哪个工具？有何论据？你得到什么回应？花了多少钱？哪里卡住了？人类认可什么吗？错误是模型、工具、提示、数据还是权限错误？

124

125这里的代理更像是分布式系统而不是聊天机器人。

126

127You need readable traces, not just text logs.您需要能够重播跑步。有必要在已知任务上比较同一代理的两个版本。我们需要衡量回归：它不仅“回答得更好”，而且“在不触及未经请求的文件的情况下关闭正确的票证”。

128

129代理评估比文本评估更困难，因为它们包括操作。比较预期的字符串是不够的。你必须考虑序列、副作用、人工制品的质量、时间、成本、人工干预的数量。

130

131有趣的是，我们总是回到那里：软件工程。测试、环境、跟踪、回滚。除了代码现在还决定下一步做什么。

132

133## 第七块：人机界面

134

135代理不必只生活在聊天中。

136

137有些代理商需要董事会。其他页面包含状态和日志。其他人有一个“批准”按钮。更多内嵌评论。还有一些 CLI。

138

139UI 改变行为。如果控制代理的唯一方法是编写长消息，则用户会给代理发出模糊的指示。然而，如果他看到计划、差异、来源、风险和下一步行动，他就可以精确干预。

140

141良好的代理基础设施包括控制面：

142

143- 当前状态；

144- 可编辑的计划；

145- 制作的文物；

146- 差异；

147- 批准请求；

148- 年表；

149- 停止按钮；

150- 重试按钮；

151- 可见的权限。

152

153这看起来微不足道，但事实并非如此。 “令人毛骨悚然的人工智能”和“可靠的助手”之间的区别通常只是后者向你展示了它的手脚。

154

155## 心理堆栈

156

157如果我今天画它，最小的代理堆栈将是这样的：

158

1591.模型：推理、生成、工具调用、必要时多模态。2.编排：循环、步骤、规划器、策略、人机循环。3. 持久运行时：工作流、队列、重试、暂停、恢复。4. 沙箱：代码执行、隔离文件系统、限制、工件。5.工具层：MCP、内部API、浏览器、数据库、存储库。6. 身份层：OAuth、范围、秘密、审计、策略。7. 内存层：项目上下文、检索、指令、过期。8. 可观察性：跟踪、重放、评估、成本和质量指标。9. 产品表面：足够时聊天，需要时仪表板，重要时进行审查。

160

161代理框架主要涵盖了第2点和第1点的一部分。剩下的就是真正的工作了。

162

163## 我在实践中会做什么

164

165如果一个团队告诉我“我们想要生产中的代理”，我不会从十个代理开始。

166

167I would start with a small, repetitive and observable workflow.例如：开放维护 PR、更新已关闭问题的文档、准备每周审查、分类重复错误、为受影响的文件生成测试。

168

169然后我会设定非常明确的限制：

170

171- 没有分支或沙箱就不能写作；

172- 提示中没有秘密；

173- 列入白名单的工具；

174- 人类对外部行为的批准；

175- 强制日志和跟踪；

176- 每次运行的预算；

177- 输出始终可检查。

178

179只有这样我才会扩展。

180

181智能体不会仅仅因为模型出错而失败。它们之所以失败，是因为我们将它们置于模糊的环境中，具有令人困惑的权限和戏剧性的期望。

182

183## 我的阅读

184

185代理基础设施在最好的方面是无聊的。

186

187这并不是演示中让你鼓掌的部分。这是让您在周一早上实际使用演示的部分，涉及真实的人员、真实的数据和真实的结果。

188

189代理人的未来不仅仅取决于谁拥有最好的榜样。 It will be decided by whoever builds the best place in which to make him work: isolated when he experiments, connected when needed, always observable, authorized with criteria and humble enough to stop when he doesn't know.

190

191这就是代理不再是玩具而是成为基础设施的地方。

192

193## 来源

194

195- [Vercel：如何使用 Vercel 和 AI SDK 构建 AI 代理](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

196- [Vercel 文档：沙箱](https://vercel.com/docs/sandbox)

197- [Vercel 文档：使用沙箱](https://vercel.com/docs/sandbox/working-with-sandbox)

198- [Vercel 文档：MCP](https://vercel.com/docs/mcp)

199- [模型上下文协议：规范](https://modelcontextprotocol.io/specification)

200- [OpenAI：构建代理的新工具](https://openai.com/index/new-tools-for-building-agents/)

201- [Cloudflare 博客：Cloudflare 上的代理](https://blog.cloudflare.com/agents-on-cloudflare/)

202