单点智能体在企业里活不过两周——工具调用可靠性下降、上下文断裂、无统一监控。本文拆解硅基团队四层平台架构（工具层→记忆层→编排层→治理层），给出 5 个关键工程取舍决策树，附某零售企业 Token 浪费降 40% 的真实路线图。
这也是本文的起点：企业不缺能跑通 Demo 的单个 AI 执行单元，缺的是一个让多个智能体稳定协作、成本可控、出了问题能定位的平台。以下从四个层面拆解 AI Agent 平台搭建的工程路线图。
我们在多个项目里看到同一个模式：POC 阶段表现惊艳，两周后就被运维团队喊停。这个问题并不新鲜——我们在另一篇分析中拆解过，90% 的企业智能体走不出 POC，根因不在模型能力，而在工程基建缺失。具体来说，三个工程问题最为致命。
第一，工具调用可靠性随任务长度衰减。 单个执行单元调用 3 个工具时准确率还能维持在 90% 以上，但一旦任务链超过 7 步，累积错误概率会快速攀升。InfoQ 论坛上周祥给出的公式值得贴在工位上：实际 Token 成本 = Token 单价 ÷ 任务成功率。成功率从 95% 掉到 65%，意味着你的单位有效产出成本翻了三倍。[1]
第二，上下文断裂导致重试成本爆炸。 智能体在多轮对话中丢失早期的约束条件，执行到第 4 步时已经忘了第 1 步的前提。它不会报错——它只会继续往下跑，用错误的前提产出错误的结果。等你发现时，Token 已经烧掉了几十万。
第三，没有统一监控。 三个执行单元各自跑在不同的服务器上，日志格式不统一，出了问题只能挨个查。一个节点的失败会级联影响下游，但没人能在第一时间看到全景。单点方案的"能用"和平台级的"可控"之间，隔着一整套基础设施。
要让 AI 执行单元从单点工具变成可治理的"硅基团队"，平台需要在四个层次上补全能力。每层解决一个核心问题。
MCP（Model Context Protocol）是 Anthropic 推出的开放标准，定位类似"AI 世界的 USB-C"——让任何 AI 应用通过统一协议连接数据库、API、文件系统等外部工具。[2] 截至 2026 年 7 月，Claude、ChatGPT、VS Code、Cursor 等主流工具都已原生支持 MCP。关于 MCP 在真实项目中的调试经验，我们在Safari MCP 落地实践中有更详细的记录。
选 MCP 还是自建 tool calling？如果企业只用到 2-3 个固定 API，自建完全够用。但当工具数量超过 10 个、且需要跨团队共享时，MCP 的标准化优势开始显现：工具即插即用、Schema 自动发现、权限集中管理。代价是 MCP Server 需要独立部署和维护——它不是一个"零成本"方案。
智能体的短期记忆靠上下文窗口，但上下文窗口不是无限长的，也不是免费的。更关键的是，每次新任务都从零开始，智能体无法复用上次任务中积累的经验。这就是周祥提出的"记忆工程"要解决的问题。[1]
记忆层拆成三个子能力：记忆蒸馏——把散落在文档、邮件、表格中的经验转化为结构化 JSON 和知识图谱；记忆计算——处理冲突、遗忘、合并，避免"同一件事两个版本"；记忆堆叠——隔离低质量经验和个人偏见，只让经过验证的最佳实践进入组织共享记忆池。
技术选型上，向量数据库（Pinecone / Milvus / Weaviate）负责语义检索，关系数据库负责结构化事实存储，两者通过统一 API 对外暴露。实践中踩过的坑：向量检索的 top-K 结果不等于"正确结果"，需要加一层重排序和事实校验，否则执行单元会拿着相似但不相关的"记忆"做推理。
编排层决定了多个执行单元之间如何分工、通信、处理异常。三种主流路线差异明显：
| 维度 | LangGraph | CrewAI | 自研（事件驱动） |
|---|---|---|---|
| 编排模型 | 有向图（状态机） | 角色分工 + 顺序任务链 | 消息队列 + Worker 池 |
| 适合场景 | 复杂分支 + 条件回退 | 固定流程的协作任务 | 高并发 + 异步长任务 |
| 人工介入 | 原生 interrupt / resume | 需自行封装 | 灵活但需自建 |
| 学习曲线 | 中等偏上 | 低 | 高（需分布式经验） |
| 生产成熟度 | 2026 年已验证 | 快速迭代中 | 取决于团队 |
| 典型规模 | 5-20 个执行单元 | 3-8 个执行单元 | 20+ 个执行单元 |
华为 2012 实验室的 ACE Harness 系统选择了自研路线：为开源社区（仓颉编程语言）构建了一套多智能体协作框架，其中有负责定位问题的角色、负责反向审视的"蓝军"角色、以及在分歧时做仲裁的"裁判"角色。[1] 这套架构的核心思路是：不让单个执行单元在同一个上下文里做完所有事，而是引入角色分工和对抗验证——这和 Qoder Desktop 的 Experts Mode（Leader + 专家角色）思路一致。[3]
前三个层让智能体"能跑"，治理层让它"能被管理"。三个必建能力：
成本仪表盘：按执行单元、按项目、按任务类型拆分 Token 消耗。不是看总额，而是看"有效 Token / 总 Token"的比例。当这个比例低于 60%，说明系统在大量做无效重试。
权限模型：智能体调用工具时需要什么权限？谁批准？InfoQ 论坛上提出的 Workspace-Actor-Project 框架是一个实用参考：记忆读取可以跨 Project，但写入必须落到明确的主 Project 和 Actor 之下。[1]
审计日志：每一步决策——调了什么工具、读了什么数据、产出了什么结论——都需要可追溯。不是为了合规而合规，而是为了在系统做出错误决策时，你能复盘出"它在哪一步开始偏离"。
以下 5 个决策点在每个 AI Agent 平台搭建项目中都会遇到，没有绝对正确，只有适合当前阶段的选项。
1. 开源框架 vs 商业平台。 团队有 3 人以上 ML 工程能力 → 选 LangGraph 或自研；团队以业务开发为主 → 考虑 Dify、Coze 等商业平台先跑通 POC。关键判断标准不是功能对比表，而是"出了 bug 你能不能自己修"。
2. 单租户 vs 多租户。 内部工具型场景（客服、IT 运维）单租户足够。如果你做的是给外部客户用的平台，多租户是必选项——但数据隔离、配额管理、租户级监控的工程成本会比预期高 2-3 倍。
3. 同步 vs 异步通信。 执行单元 A 调用 B 后是等结果还是发消息后继续？答案取决于任务 SLA。实时对话场景必须同步（用户不会等 30 秒），但数据分析、报告生成等长任务用异步消息队列更稳定——B 挂了不会拖死 A。
4. 状态外挂 vs 模型原生记忆。 把状态存到外部数据库（Redis / PostgreSQL）比依赖模型自身的上下文窗口更可控——你可以随时查看、修改、回滚。代价是多一次网络 IO。我们一开始全部用了模型原生记忆，上线后发现在长任务中状态丢失率超过 15%，最终全部迁移到外挂方案。
5. 人工介入深度。 Human-in-the-Loop（HITL）和 Human-on-the-Loop（HOTL）的区别：前者是人在关键节点进入流程（审批高风险操作），后者是人在系统上方做治理（定规则、观状态、控边界）。[1] POC 阶段用 HOTL（减少人工介入加快验证），生产环境必须加入 HITL（高风险操作不能自动执行）。
一家中型零售企业 2025 年底同时跑着 3 个独立 AI 模块：客服问答模块（接 GPT-4o）、商品推荐模块（接 Claude）、库存预警模块（自训练小模型）。三套系统各自有独立的数据管道、监控和部署流程，互不通信。
问题在 2026 年 Q1 集中爆发：客服模块承诺了已售罄商品的到货日期，因为它读不到库存系统的实时数据；推荐模块向用户推荐了促销已结束的商品，因为促销规则变更没有同步给它。运维团队每周至少要花 6 个小时排查这类"跨系统信息不一致"问题。
2026 年 3 月，团队启动统一平台搭建。关键动作：
4 个月后的数据：跨系统信息不一致的工单从每周 13 个降到 2 个；Token 浪费（无效重试 + 上下文断裂导致的重跑）下降约 40%；任务端到端完成率从 62% 提升到 89%。
踩过的三个坑：① MCP Server 的冷启动延迟在高峰期达到 3-5 秒，需要加预热和连接池；② 向量检索的相似度阈值调了 3 轮才稳定——太高漏召回、太低引入噪音；③ LangGraph 的 interrupt 机制在并发场景下偶发死锁，需要加超时兜底。
这套平台不是一步到位的。按以下三个阶段推进，每阶段有明确的成功标准和预算预期：
阶段一：POC 验证（2-4 周，预算 5-15 万）。 选一个最痛的场景（如客服 + 知识库），用 1-2 个执行单元跑通"工具调用 + 记忆存储 + 基础监控"的 MVP。成功标准：任务完成率 ≥ 70%，单次任务 Token 消耗可追踪。POC 阶段最容易低估的是工程基建工作量——我们在AI Agent 生产化部署中详细拆解过，POC 跑通只意味着完成了 30% 的工作。
阶段二：小团队试点（1-3 个月，预算 20-50 万）。 引入编排层（LangGraph 或 CrewAI），扩展到 3-5 个执行单元协作，上线成本仪表盘和基础权限模型。成功标准：跨单元任务完成率 ≥ 85%，月度 Token 浪费率 < 20%。
阶段三：全组织铺开（3-6 个月，预算 80-200 万）。 完善治理层（审计日志 + 细粒度权限 + HITL 机制），支持 10+ 执行单元的多租户部署。成功标准：平台可用性 ≥ 99.5%，决策审计覆盖率 100%。
每个阶段的预算范围取决于你是用开源框架自建还是采购商业平台。如果团队已经有 ML 工程基础，阶段一可以控制在 5 万以内（主要是人力 + API 费用）。
如果你正在评估 AI Agent 平台搭建方案，可以联系我们做一次免费的技术选型咨询，或者查看我们的企业 AI 落地案例。
Function Calling 是模型层面的能力——模型输出一个"我想调用这个函数"的信号，由你的代码实际执行。MCP 是连接层面的标准——定义 AI 应用如何发现、连接、调用外部工具。两者不冲突：MCP Server 通常就是通过 Function Calling 被调用的。MCP 的价值在于标准化——换了模型或工具，不需要重写调用逻辑。
如果你只有 1-2 个执行单元且它们之间不需要协作，编排层是过度设计。但一旦出现"单元 A 的输出是单元 B 的输入"这种依赖关系，没有编排层你会发现自己在一堆 if-else 和轮询逻辑里越陷越深。建议在执行单元数量达到 3 个时开始引入轻量编排。
按 2026 年 7 月的价格，一个中等规模部署（5 个执行单元，日均 500 次任务调用，使用 GPT-4o 级模型）：API Token 费用约 8,000-15,000 元/月，向量数据库约 1,500-3,000 元/月，服务器和 MCP 基础设施约 3,000-6,000 元/月。合计 12,000-24,000 元/月。如果使用开源模型（如 DeepSeek、Qwen）自部署，Token 成本可降至上述的 1/5 到 1/3，但需要额外的 GPU 服务器投入。
如果你的任务流有复杂分支和条件回退（"如果步骤 3 失败，回退到步骤 1 用不同参数重试"），选 LangGraph——它的图结构天然支持这类逻辑。如果你的任务流是相对固定的线性协作（"研究员出报告 → 写手改写成文案 → 审校做最终检查"），CrewAI 的角色分工模型更直观，上手更快。
