很多人以为做一个 AI Agent就是“接个大模型 写一段提示词”。真到要长期运行、要接真实系统的时候才会发现缺的往往不是模型而是模型周围那一圈基础设施。一、工具层Agent 的手和脚模型本身只会输出文字。要让它“做事”就得把外部能力包装成工具Tool / Function Calling暴露给它搜索、读文件、查数据库、发请求。这两年一个明显的变化是接口在收敛。**MCPModel Context Protocol**正在成为把工具接给模型的通用做法——工具方按协议实现一次多个模型和客户端都能复用。协议统一之后真正要花心思的地方变成了权限给 Agent 一批工具等于给了它一批能力最小权限原则在这里同样适用。二、记忆层上下文放不下那么多上下文窗口再大也是有限的而且越长越贵。想把用户偏好、历史结论、项目背景长期带上就需要一层记忆短期记忆当前会话的上下文用完即弃。长期记忆把重要信息抽取成结构化条目或向量存起来需要时再检索回来。一个常见误解是把记忆等同于“把聊天记录全塞回去”。真正有效的做法是有选择地记记事实、记偏好、记结论而不是记每一句寒暄。三、执行层能跑代码就必须能隔离当 Agent 需要执行脚本、装依赖、访问网络时直接在你的机器或生产容器里跑是危险的。合理做法是丢进一次性沙箱给一个干净的、用完即销毁的环境限制它能访问什么出了事也不污染主系统。判断标准很简单如果 Agent 写的代码有 bug或者被提示注入带偏最坏情况是什么如果答案是“整台机器受影响”那就该上沙箱。这类能力如今也有现成服务面向 Agent Runtime 的云沙箱就是其中一种形态用完即回收适合不适合自建取决于团队规模。四、接入层把上面这些统一起来工具、记忆、沙箱都是能力能力一多管理就成了新问题模型来自多家供应商Key、额度、限流怎么统一每次调用谁在用、花了多少、失败原因是什么某个供应商挂了能不能自动切到备选这些问题属于接入与治理通常用一个统一网关来解决对外一个入口对内管理供应商、模型、成员权限与调用审计。五、现成方案与自建的取舍上面四层都可以自建也有平台把它们做成了现成服务。以国内的一个例子来说长亭百智云把这几层拆成了可分别接入的产品Agent 工具包一个 Key 调搜索、解析、图像工具、长期记忆服务、面向 Agent Runtime 的云沙箱以及统一聚合多源 MCP 的网关再往上是模型商店和大模型 API 管理网关负责模型接入与额度、审计。自建和用现成服务各有取舍自建可控、可定制但每一层都要人维护现成服务开箱即用代价是受它支持的形态约束。多数团队的现实路径是——先用现成的把流程跑通等某一段真的成为瓶颈再替换成自建。小结Agent 的能力上限往往不取决于模型有多强而取决于它周围那层基础设施搭得是否扎实工具给边界记忆给连续性沙箱给安全网关给可观测与可治理。把这四层想清楚再决定是自建还是接入比一上来就纠结“用哪个模型”更接近能落地的答案。