实战五：公司内部 AI 平台长什么样

本文是《从 0 写 Agent》系列第 49 章。这个系列基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版），用 Go 从零实现一个生产级 Agent 运行时；本章讲「实战五：内部 AI 平台」。

前四个案例是"单个 Agent 应用"。这一章往上走一层，做一个"内部 AI 平台"，让企业里不同团队都能在上面配自己的 Agent。

这是 agents-server（Part VI）在真实企业的延伸，从"单应用"到"平台"。

从应用到平台

单应用（前 4 个案例）和平台的区别：

平台的核心，"Agent 定义是数据，不是代码"。 用户在 UI 里配 Agent（选模型、写指令、挂工具），不用改代码重新部署。

平台架构

agents-server（Part VI）已经是个平台雏形。扩展到企业级：

内部 AI 平台
├── Agent 配置层（数据库）
│   └── 每个团队配自己的 Agent（模型/指令/工具/handoff）
├── 运行层（bridge）
│   └── 把配置组装成 SDK Agent，跑流式
├── 工具生态层
│   ├── MCP servers（数据库/API/文档）
│   ├── Sandbox（跑代码）
│   └── Skills（共享技能）
├── 治理层
│   ├── 权限（谁能用哪个 Agent）
│   ├── 审计（记录所有操作）
│   ├── 成本（按团队归因）
│   └── SLO（监控延迟/错误）
└── 前端
    └── 各团队的 Agent 工作台

配置驱动的 Agent

平台的 Agent 不是代码定义，是数据库记录（第 35 章的 agent_configs 表）：

{
  "id": "agent_finance",
  "name": "财务分析助手",
  "model": "openai/gpt-4o",
  "instructions": "你是财务分析师...",
  "tools": ["get_order", "run_analysis"],
  "mcp_servers": ["finance_db"],
  "handoffs": ["agent_auditor"],
  "guardrails": ["no_pii", "max_length_5000"],
  "approve_tools": ["process_refund"],
  "retry_policy": {"max_attempts": 3}
}

财务团队在 UI 里配这个，保存到数据库。运行时 bridge 层把它组装成 SDK Agent。 不用写代码，不用重新部署，改配置立即生效。

这是 agents-server 的 bridge.BuildFullAgent（第 34 章）做的事，DB 配置 → SDK Agent 的转换。

多团队治理

权限

// 每个 Agent 配置有 owner_team
type AgentConfig struct {
    OwnerTeam string `bun:"owner_team"`
}

// 查询时只返回当前用户有权的
func ListAgents(ctx, user) {
    teams := user.AccessibleTeams()
    return store.ListByTeams(teams)
}

财务团队的 Agent，市场团队看不到。 这是多租户的基本隔离。

审计

所有 Agent 操作记 trace（第 25 章），存到 trace_events 表（第 35 章）：

SELECT agent_id, tool_name, output, created_at
FROM trace_events
WHERE team = 'finance' AND created_at > '2026-06-01';

审计能回答"谁、何时、用了哪个 Agent、做了什么"。 这是合规的基础。

成本归因

每个 Agent 调用记录 Usage（token 消耗），按团队归因：

SELECT team, SUM(input_tokens + output_tokens) as total_tokens
FROM trace_events JOIN agent_configs ...
GROUP BY team;

财务团队这个月花了多少 token，一查就知道。 按团队计费、设预算上限。

共享工具生态

平台的价值在于"工具复用"，

• MCP servers，公司建一个"CRM MCP server"，所有需要查客户数据的 Agent 都能用（第 28 章）
• Skills，写一个"写周报"的 Skill，所有团队共享（第 30 章）
• Sandbox，统一的代码执行环境（第 32 章）

工具一次开发，所有 Agent 复用。 这是平台相比"每个团队自己搭 Agent"的核心优势。

平台的演进路径

从单应用到平台，分阶段：

阶段一：单 Agent 应用

先用 agents-go 写一个具体 Agent（客服/分析/代码）。验证 Agent 在你的场景有效。

阶段二：多 Agent + agents-server

用 agents-server 跑几个 Agent，加上 Web UI、Session 持久化、HITL。此时还是"几个独立应用"。

阶段三：内部平台

把 Agent 定义搬到数据库（配置驱动），加权限/审计/成本治理。让多团队自助配置 Agent。

阶段四：企业级平台

补上《企业 Agent 平台工程》讲的，多租户、SLO、评测、合规映射、组织流程。

agents-go + agents-server 支撑阶段一-三。阶段四要补工程化能力（参考附录 B）。

小结

内部 AI 平台的核心：

1. 配置驱动，Agent 定义是数据，不是代码
2. bridge 层转换，DB 配置 → SDK Agent
3. 治理三件套，权限、审计、成本归因
4. 工具复用，MCP/Skills/Sandbox 一次开发多 Agent 共享
5. 分阶段演进，单应用 → 多 Agent → 平台 → 企业级

从"写一个 Agent"到"搭一个平台"，是 Agent 工程化的完整路径。 agents-go 教你前者，agents-server + 企业平台工程书教你后者。

Part IX 回顾

第 45-49 章，五个实战案例：

五个案例，从单 Agent 到多 Agent 到平台，覆盖了 Agent 应用的完整谱系。

下一篇

第 50 章，Part X 对比与选型，agents-go vs LangChain。两个 Agent 框架的设计哲学差异、优劣势、选型建议。

本文是《从 0 写 Agent》系列第 49 章，案例代码基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版）。全系列目录见总览。