自研、平台还是托管 | 从零理解如何构建 AI Agent

帮助你快速判断本章定位、前置要求与学习目标。

不要先问买不买

Build vs Buy 不是采购问题，而是控制权问题。

先问三个问题：

1. 哪些能力必须由团队自己控制？
2. 哪些能力只是通用基础设施？
3. 哪些能力交给平台后会形成迁移风险？

如果这些没说清楚，讨论自研还是采购只会变成偏好之争。

先拆能力，不要整包判断

Agent 系统可以拆成：

Model Provider
  -> Agent Runtime
  -> Tool Gateway
  -> Knowledge Pipeline
  -> Observability
  -> Evaluation
  -> Security / Approval

很少有团队应该全部自研，也很少有严肃企业场景能全部外包。更常见的答案是"买基础能力，自研控制边界"。

四种路线

路线	适合	优点	风险
轻量自研	简单工具调用、强业务控制、小范围场景	透明、依赖少、容易调试	状态和评估能力要自己补
开源框架	需要 Agent loop、RAG、工具生态	起步快，社区成熟	抽象边界和版本迁移要控制
托管 Agent 平台	交付速度优先、平台栈统一	集成快，运维少	provider 锁定、可观测性受限
垂直 SaaS	标准业务场景，如客服、销售、知识库	上线快，业务功能完整	定制深度和数据边界受限

不要把"自研"理解成从零造全部组件。更多时候是：核心业务流程自研，模型、搜索、向量库、观测部分用成熟服务。

组件级取舍

组件	更适合买	更适合自研
模型 API	通用推理能力	极少数私有模型场景
向量库	托管可用、运维少	强合规、自托管要求
搜索/Reader	外部网页能力	内网搜索和私域抓取
Agent Runtime	原型和平台内产品	强状态、强审计、多 provider
工具网关	标准 SaaS 集成	业务权限复杂、高风险工具
评测集	工具可买	样本和判断标准必须自有
审批和审计	平台可辅助	高风险动作必须自控

评审时不要问"这个 Agent 买还是自研"，要问"哪一层买，哪一层自研"。

托管平台 vs 自建 Runtime

维度	托管平台	自建 Runtime
交付速度	快	慢
状态控制	受平台限制	可自定义
工具治理	依赖平台能力	可接入自有权限
Trace	平台内好用	可进入自有观测
迁移成本	高	低到中
运维成本	低	高
合规控制	需要评估	可定制

每一层控制权放在哪里：

层	可以托管	建议自控
模型调用	provider、模型 API	路由策略、fallback 策略
对话界面	低风险原型	企业身份和权限
工具执行	沙盒工具、低风险动作	工具网关、高风险审批
状态存储	临时 demo 状态	业务状态、审批状态
Trace	平台调试视图	可导出的审计和回放数据
Eval	平台评分能力	自有样本集和通过标准

判断顺序

是否是标准业务场景？
  -> 是：先看垂直 SaaS
  -> 否：继续

是否强依赖某个云或模型平台？
  -> 是：评估托管 Agent 平台
  -> 否：继续

是否需要自定义状态、权限、工具和审计？
  -> 是：框架 + 自研业务层
  -> 否：轻量自研或平台能力

是否只有简单工具调用？
  -> 是：轻量自研
  -> 否：框架或托管平台

什么必须自己控制

通常不建议完全交给黑盒平台的部分：用户权限、工具白名单、高风险操作审批、审计日志、业务状态 schema、评测集、成本和延迟策略、数据删除和版本治理。

什么可以优先买：模型 API、Embedding、向量数据库、搜索 API、网页读取、基础 trace、文档解析、监控告警。

这些能力重要，但不是每个团队都值得从零维护。

供应商锁定评估

锁定不是一层

Agent 平台锁定通常发生在多层：

Model -> Tool Schema -> Agent Runtime -> State -> Trace -> Eval -> Data Policy

只看模型能不能替换是不够的。真正难迁移的通常是状态、工具、trace 和评测。

锁定分两类

类型	含义	处理
可接受锁定	换掉会麻烦，但不伤业务核心	写清楚成本即可
不可接受锁定	锁住权限、状态、审计、评测	不建议上线

层	风险	可接受条件
模型	提示词和输出格式绑定	有模型路由和回归评测
工具协议	工具 schema 不能复用	工具定义可导出
Runtime	状态和流程绑定平台	业务状态可外置
Trace	只能在平台内看日志	trace 可导出或回放
Eval	评测集只存在平台内	样本和评分标准自有
数据	保留、删除策略不透明	合规条款明确

可替换 vs 可治理

能力	可替换	可治理
模型	能切到另一个 provider	有评测集、回归样本和输出差异报告
工具	能改成另一个 schema	有权限、审计和参数校验
Trace	能下载日志	能回放关键案例
RAG	能重建索引	保存原文、chunk、metadata 和版本
Runtime	能重新实现流程	状态机和业务状态由自己掌握

只可替换但不可治理，迁移后很难判断系统是否仍然安全、准确和可审计。

迁移演练

评估平台时做一个小演练：

导出 20 条典型 trace
导出工具 schema
导出或复现 prompt / policy
用另一套 runtime 重放 5 条样本
对比输出、工具调用和引用

如果这个演练做不到，说明你并不知道退出成本。

必问问题

评估供应商时，至少问：Prompt 和工具定义能否导出、trace 能否批量导出、状态 schema 是否由你控制、是否能替换模型、是否能接入自己的权限系统、是否能接入自己的评测集、数据删除和保留策略是否清楚、迁出后是否能继续回放历史案例。

采购评审怎么写

问题	示例回答
锁在哪里	模型、trace、runtime 状态
为什么接受	第一阶段只做低风险内部问答
退出触发条件	成本超过预算、合规要求变化、质量下降
退出动作	导出 trace、重放样本、切换模型路由
最坏后果	短期无法回放历史会话

降低锁定的方法

• 把业务状态放在自有数据库；
• 工具 schema 使用平台无关定义；
• 保留自己的评测集；
• 保存关键 trace；
• 模型调用加路由层；
• RAG 数据和索引构建流程自有；
• 高风险工具审批放在自有系统。

第一版不一定要做完整平台抽象，但至少做三件小事：保存自有评测样本和期望输出、保存工具 schema 参数和执行结果、保存关键 trace 的平台无关摘要。

一个常见演进路径

阶段 1：托管平台做 POC
  -> 验证任务价值、样本集、用户体验

阶段 2：抽出工具网关和权限
  -> 高风险动作进入自有审批

阶段 3：抽出状态和 trace
  -> 关键流程可回放、可审计

阶段 4：平台变成能力供应商
  -> 模型、搜索、追踪服务可替换

这个路线的重点不是一开始就自研所有组件，而是不要让第一版原型把长期控制面锁死。

混合控制面

一个更稳的生产架构通常是：

自有控制面
  -> identity / permission
  -> tool gateway
  -> business state
  -> eval dataset

外部能力面
  -> model
  -> search
  -> vector db
  -> hosted tracing

控制面决定业务安全，能力面决定交付效率。

常见错误

错误	问题
为了快把权限放进平台黑盒	后续很难接企业权限体系
只评估 demo 效果	忽略状态、审计和迁移
自建等于全部自研	浪费在非核心能力上
平台 trace 不可导出	生产事故无法独立复盘
只问"能不能换模型"	不关心换了之后能否证明没有退化
"先上线再考虑迁移"	评测样本和 trace 没保存，后面迁移无依据

推荐路线

阶段	推荐
想验证需求	垂直 SaaS 或轻量原型
想验证技术路径	开源框架 + 小范围 POC
已有明确业务流程	自研业务编排 + 成熟基础设施
强平台生态产品	托管 Agent 平台
高权限、高审计场景	自研控制层 + 可替换外部服务

典型组合

项目	推荐组合
内部制度问答	托管模型 + 自有 RAG 数据治理
企业 Copilot	自有权限和工具网关 + 外部模型
代码库 Agent	自有 workspace/runtime + 可替换模型
客服知识库	垂直 SaaS 或 RAG 产品先验证
研究型 Agent	搜索/Reader 服务 + 自有来源评估

最终判断

好的 Build vs Buy 决策应该能说清楚：哪些能力买、哪些能力自研、为什么这些能力必须自己控制、如果平台不满足预期怎么迁移、POC 通过后生产缺口是什么。

能导出：可评估
能替换：可优化
能回放：可治理
能迁移：可接受
不能解释退出路径：高风险锁定

短期验证：托管平台
标准场景：托管或 SaaS
强控制：自建 Runtime
高审计：自有状态和 trace
长期平台：自建控制层 + 外部能力

托管平台可以让你快，但自有 Runtime 决定你能不能长期改、查、迁和控。选择的关键是：业务规则、权限、评测和审计不要完全外包。