第2章 企业级 Agent 平台的边界¶
场景引入¶
第一个 Agent 往往可以由业务团队自己推进：选一个场景，接几个工具，做出能演示的闭环。第二个、第三个 Agent 出现后，问题就会从“单点能不能做”转向“多条智能项目线如何长期共存”。报价 Agent、经营分析 Agent、工单 Agent、票据 Agent 可能都在调用模型、读取企业数据、写入业务系统，却各自维护身份、权限、日志、评测和成本口径。
一家多业务线企业第一年做了几个成功试点：制造板块生成报价草稿，零售板块生成经营分析材料，客服中心做工单摘要，财务共享中心做票据识别。第二年，安全团队开始追问哪些 Agent 可以读取客户明细；财务团队追问模型成本应归到哪个部门；平台团队需要知道一次错误工具调用对应哪个模型版本、工具参数和审批状态；业务团队则发现，不同 Agent 对同一个“销售额”给出了不同口径。
这些问题已经无法靠某个项目组继续补代码解决。当 Agent 数量增加后，口头约定会迅速失效：谁注册工具、谁审批权限、日志写到哪里、模型升级影响哪些场景、失败后谁接管，都需要稳定的公共机制。
图2-1：多 Agent 共享平台边界。来源：本书自绘。Alt text：上层是报价、经营分析、工单、票据等面向不同任务的业务 Agent，下层是模型、数据、工具、流程、治理五类共享能力，箭头表示所有业务 Agent 都通过统一平台层访问这些能力。
Agent 平台的价值，不是再做一个“更大的 Agent”，而是把模型、数据、工具、运行和治理中的共性责任沉淀为统一契约。 业务 Agent 可以不同，业务团队也可以保留自己的产品节奏，但模型入口、工具契约、权限审批、运行记录、评测和审计等底线不能各做一套。
平台也有反向边界。平台太薄，会退化成模型代理；平台太厚，又会吞掉业务规则，使每次折扣策略、工单优先级或报表模板变化都要等待平台排期。合理的平台只在必须统一的地方强约束，在业务变化快、试错频繁的地方保留自主空间。
2.1 应用、框架与平台：先分清三层责任¶
Agent 领域最常见的概念混乱，是把应用、框架和平台混在一起。
表2-1：Agent 应用、框架与平台三层各自解决的问题。来源：本书整理。
| 层级 | 它解决什么问题 | 典型样子 |
|---|---|---|
| Agent 应用 | 某个具体业务任务怎么完成 | 报价 Agent、DataAgent、工单 Agent |
| Agent 框架 | 单个 Agent 怎样编排状态、调用工具、组织记忆 | LangGraph、AutoGen、CrewAI、自研编排框架 |
| Agent 平台 | 多个 Agent 如何共享能力并被统一治理 | 模型网关、工具注册、Runtime、Trace、Eval、Policy |
应用回答“这个业务任务怎么完成”；框架回答“怎样把一个 Agent 写出来”；平台回答“如何让许多 Agent 在企业里长期运行，同时共享能力、避免重复建设并接受统一治理”。
因此，企业完全可以允许不同应用团队使用不同框架，同时要求所有生产 Agent 遵守统一平台契约。低代码工具、Agent Studio、可视化编排器也应放回这个三层结构判断：它们可能让搭建一个 Agent 更快，但只有当模型调用、工具定义、权限、Trace、评测和发布规则能够跨应用统一时，才真正进入平台层。
判断“是不是平台”，不要看有没有控制台和拖拽界面，而要看它是否承担了跨 Agent 的统一责任。 如果每个项目仍然自己接模型、自己定义工具、自己做审批和日志，那么企业拥有的仍是一组应用，而不是平台。
2.2 平台真正管理什么：五类共性问题¶
企业级 Agent 平台看起来会包含很多组件，但它真正管理的是五类反复出现的问题：
- 模型：调用哪个模型，怎样路由、限流、降级，成本如何归集。
- 数据：能看哪些数据，采用哪套指标口径，以什么身份访问，如何脱敏。
- 工具：有哪些可调用能力，谁能调用，参数是否合法，动作是否产生副作用。
- 流程：什么可以自动执行，什么必须等待人工，高风险动作如何审批，长任务失败后怎样恢复。
- 治理：怎样评估、记录、回放、审计，并把失败样本持续反馈到发布和运营。
图2-2：平台管理的五类共性问题。来源：本书自绘。Alt text：模型、数据、工具、流程、治理五个并列区块，每个区块下列出对应的共性问题（如模型的路由与成本、工具的权限与副作用、治理的审批与回放），表示这些问题在多个业务 Agent 间重复出现、应由平台统一承接。
Agent 平台会借用数据平台、身份平台、审批平台和应用平台的资产，但并不替代它们。数据平台仍负责数据资产与治理，身份平台仍负责主体和权限体系，审批平台仍负责确定性审批流程；Agent 平台新增的责任，是把模型决策、工具副作用、人工确认、任务状态、Trace 和评测串进同一条执行链。
平台不是“组件集合”，而是五类共性问题的统一解法。 企业通常不是先画好一张架构图再产生平台，而是多个项目反复遇到同样的成本、权限、工具和审计问题，平台才被真实需求“逼”出来。
2.3 哪些能力应该平台化：复用、风险与变化速度¶
决定某项能力放在平台还是业务侧，可以先问四个问题：
- 是否会被多个 Agent 重复使用？
- 是否影响权限、成本、审计或评估？
- 是否高度依赖某个业务域的特殊规则？
- 平台化后是否能明显降低后续接入和维护成本？
表2-2：常见能力更适合归平台还是留给业务及其原因。来源：本书整理。
| 能力 | 更适合的平台归属 | 原因 |
|---|---|---|
| 模型调用入口 | 平台 | 所有 Agent 都会重复用，且涉及成本与限流 |
| 工具注册与风险等级 | 平台 | 直接影响副作用控制与审计 |
| 统一审批通道 | 平台 | 高风险动作不能每个应用各做一套 |
| 制造板块的报价折扣规则 | 应用 | 业务域专属逻辑过强 |
| 客服中心的工单优先级策略 | 应用 | 高度依赖具体部门业务 |
| 统一 trace 字段与 run_id 规范 | 平台 | 否则无法跨 Agent 回放 |
| 语义层底座 | 平台为主 | 指标和口径需要统一 |
| 语义层中的业务解释细节 | 平台与应用共同负责 | 平台定义框架，应用补充具体域知识 |
还要考虑变化速度。高风险、强共性、变化相对稳定的能力，越早平台化越有价值；强业务差异、快速变化、低风险的能力，过早收进平台反而会拖慢创新。
平台化通常出现三个明显信号：
表2-3：提示该把能力收归平台的几个信号及其含义。来源：本书整理。
| 信号 | 它说明了什么 |
|---|---|
| 重复建设 | 不同团队在重复封装模型、工具、RAG、审批、日志 |
| 治理断裂 | 企业无法统一回答权限、成本、trace、评估的问题 |
| 接入摩擦 | 每个新 Agent 都要重新搭一遍基础设施 |
当重复建设、治理断裂和接入摩擦同时出现，继续让各项目独立演进的边际成本通常已经高于平台化成本。
平台成熟度不取决于“收进来多少能力”，而取决于共性风险是否被统一承接、业务差异是否仍有足够空间。
2.4 平台准入与治理：控制边界，不制造审批负担¶
平台一旦成立，会重新分配部分标准制定权、准入权和发布权。模型选择需要进入平台策略；工具接入需要统一契约；高风险动作需要平台与安全共同定义审批规则；Trace 要统一 Run 语义和字段；模型或流程版本的好坏，要由平台与业务共同维护评测口径，而不是靠演示印象决定。
业务团队自然会担心平台让接入变慢，安全和治理团队则担心平台把风险集中到一个黑箱中。成熟的平台必须同时解决两件事：接入效率不能被治理拖垮，高风险边界也不能因为追求效率而失控。
新 Agent 的最小准入流程可以收敛为五步：
表2-4：Agent 准入评审各步骤要回答的问题。来源：本书整理。
| 步骤 | 要回答的问题 |
|---|---|
| 任务定义 | 这个 Agent 到底负责什么，不负责什么？ |
| 工具审查 | 它要调用哪些工具，哪些只读，哪些有副作用？ |
| 风险分级 | 哪些动作可自动执行，哪些必须确认或审批？ |
| 评测准备 | 怎么判断它上线后确实比旧做法更好或至少不更差？ |
| 平台接入 | 是否纳入统一的 Runtime、Gateway、Trace、Policy？ |
图2-3：平台准入与治理机制。来源：本书自绘。Alt text：一条从左到右的准入流程，业务 Agent 按风险分级走不同路径，低风险走标准准入，中风险由平台与安全联合评审，高风险进入治理委员会，右侧汇入统一的上线与持续治理环节。
这五步的目的不是让业务排队，而是防止每个新 Agent 再制造一套技术债。低风险知识问答可以走轻量标准接入；报价草稿、经营分析等中风险任务需要工具审查、数据口径和人工确认；自动外发、主数据修改、财务处理等高风险场景，则必须确认 Policy、HITL、Trace、回滚和事故响应都能工作。
当场景数量增加后，企业还需要一个轻量但正式的治理机制。它不一定叫“治理委员会”，但至少要稳定处理三类决策：生产准入、风险边界和平台路线。治理机制不应干预每个 Prompt、页面和业务文案；它只处理跨场景、跨部门、涉及责任边界的问题。
治理的目标是统一不可妥协的底线，而不是把所有产品决策收归平台。
2.5 平台的反向边界：哪些事不应该由平台做¶
平台最容易出现的失败，不只是“能力不够”，还包括“什么都想管”。成熟平台必须明确自己不负责什么。
表2-5：平台不该做的事、越界后果与更合理的边界。来源：本书整理。
| 平台不该做的事 | 如果做了会怎样 | 更合理的边界 |
|---|---|---|
| 替业务定义目标 | 平台变成业务产品团队，责任错位 | 平台提供方法，业务定义目标 |
| 吞掉所有规则 | 平台发布被业务变化拖垮 | 平台管契约，应用管域规则 |
| 所有场景同一流程 | 低风险项目被拖慢，高风险项目又管不住 | 按风险分级管理 |
| 替代已有平台 | 架构重复，治理割裂 | 消费已有平台能力 |
| 消灭试错空间 | 业务绕开平台 | 建立沙盒与准入分层 |
平台不应替经营分析、报价、客服或财务团队定义业务目标，也不应把折扣规则、质检细则、报销口径等快速变化的领域规则写进公共核心。它更不应该重建一套平行的数据、身份或审批系统。
低风险探索需要快，高风险生产需要稳，因此平台应提供分级路径和沙盒空间。平台要管住的是生产责任，而不是消灭业务试错。 若接入平台只增加审批步骤，却不能带来更清楚的权限、更可见的成本、更完整的运行证据和更可靠的恢复能力，业务团队自然会选择绕开平台。
2.6 平台进入生产后：责任、目录、供应商与生命周期¶
Agent 平台不是一次性交付的一组功能，而是一套长期运营机制。模型版本、业务规则、工具接口、数据口径和用户使用方式都会持续变化，因此一个今天稳定的 Agent，几个月后也可能因为模型升级、规则更新或数据变化而失真。
平台运营至少需要明确四类责任：
- 平台团队：统一入口、Runtime、公共工具契约、Trace、评测框架、发布门禁和运行稳定性。
- 业务团队：场景目标、验收样本、业务规则、用户反馈和采纳结果。
- 数据团队：指标口径、数据权限、质量、血缘和语义层。
- 安全/法务/内控：风险策略、审批边界、审计和合规要求。
这种分工应贯穿需求、开发、上线和运营，而不是事故发生后再临时决定“谁负责”。同样重要的是退出机制：低使用率、长期高成本、无人维护、人工退回率过高或风险等级上升，都可以触发降级、冻结高风险工具或下线。
平台目录：每个 Agent 都要有运行档案¶
企业进入多 Agent 阶段后，需要一份可运营的平台目录。至少记录：业务 owner、平台 owner、数据 owner、风险等级、工具、模型、数据域、评测集版本、最近发布、最近复审、成本归属和退出条件。
目录不能只是展示页。Agent 新接高风险工具时，风险等级应同步变化；失败率持续升高时，应触发复查；多个部门反复建设相似能力时，应推动复用。早期可以从轻量记录开始，按季度更新使用、成本和事故情况，并进行年度正式复审。
平台目录的价值，是让每个 Agent 都有明确生命周期和责任归属，而不是让“已经上线”变成永久存在的理由。
供应商能力也必须进入统一契约¶
企业通常会混合自研和采购。外部知识库、客服质检、模型网关或行业 Agent 能否纳入平台，关键不在品牌，而在是否支持统一身份和权限、数据与工具边界、Trace 或关键运行记录导出、评测、成本归集，以及企业是否掌握关键配置和治理策略。
无论采购还是自研，只要进入企业任务链，就应接受同一套平台责任。 否则供应商产品很容易形成新的治理孤岛。
2.7 采用节奏与边界复审：平台应随证据演进¶
企业不需要第一天就把所有 Agent 迁到统一框架。早期更合理的方式，是先统一那些“高风险、强共性、后续重复成本高”的底座：模型网关、工具注册、权限策略、Runtime、Trace、基础 Eval、安全门禁和发布记录。UI、场景流程、低风险 Prompt、领域规则和业务样本则继续由应用团队快速迭代。
所有生产 Agent 至少应遵守一套最低运行契约：模型经过统一入口，工具可登记和分级，高风险动作能被拦截或审批，Trace 能关联用户、工具和证据，失败样本可以进入评测和发布门禁。满足这些契约后，业务团队是否使用同一框架并不是最重要的问题。
平台边界也不能一次划死。以下变化都应触发复审：多业务重复建设明显增加；某项能力开始接入敏感数据或写操作；审计要求变化；故障复盘发现缺少 Trace；模型成本无法归因；供应商能力发生替换；用户范围扩大；自动化比例明显提高。
复审时可以把争议拆成三类：执行责任、治理责任和资产责任。执行责任看接口契约和运行日志，治理责任看风险等级和合规要求，资产责任看复用范围、迁移成本以及 Prompt、评测样本、Trace 等资产由谁维护。每次结论都应形成具体动作：迁入平台、继续留在业务侧、暂时观察，或者退役；同时写清 owner、SLO、审计接口、迁移窗口和下次复查条件。
平台建设也有阶段差异：探索阶段允许快速试错，但必须守住数据和工具边界；生产阶段要求发布证据、owner、SLO、成本归因和事故路径；规模化阶段再进一步建立模板、目录、治理机制和组合管理。
平台化的成熟标志，不是一次性覆盖全部能力，而是边界能够随着复用价值、运行风险和真实证据有依据地扩张或收缩。
本章小结¶
企业真正困难的不是“写出一个 Agent”，而是让一组 Agent 在统一底线下长期运行。应用解决具体任务，框架解决单个 Agent 的编排，平台解决跨 Agent 的模型、数据、工具、流程和治理问题。
平台不能薄到只剩模型网关，也不能厚到接管业务目标和领域规则。应优先统一模型入口、工具契约、权限、Runtime、Trace、Eval 和高风险审批，把快速变化的业务规则、交互和领域样本留给应用团队。
企业级 Agent 平台的核心边界可以概括为一句话：统一共性能力和共性风险，保留业务判断和创新空间，并让每个生产 Agent 都有可追踪的责任、证据、成本和退出路径。 下一章将进一步讨论这些平台能力最终服务什么样的业务系统，以及 AI 原生为什么不是简单地在旧软件上增加一个聊天入口。
参考文献¶
NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0).
OWASP. (n.d.). Top 10 for Large Language Model Applications.
Model Context Protocol. (n.d.). Specification and documentation.
Kubernetes. (n.d.). Documentation.