中小企业 Agent 平台架构：从入口、编排到工具与治理的完整设计

企业 Agent 不能按照“做一个聊天机器人，再接几个 API”的思路设计。

聊天机器人解决的是回答问题；生产 Agent 解决的是完成任务。后者要识别操作者身份、读取有权限的数据、规划步骤、调用业务系统、等待审批、处理中断、验证结果，并留下可以追责和复盘的执行记录。

大型集团把这些能力建设成统一的 Agent Platform、Tool Hub、Knowledge Platform 和 Governance Center。中小企业没有必要复制一套重型中台，但不能删除这些能力。正确做法是：保留完整逻辑分层，采用轻量部署；先实现一个业务域，等复用和规模真实出现后再拆平台。

这篇文章给出的不是概念清单，而是一套可以直接拿去做技术方案评审的蓝图。

一、先看完整架构

整个系统可以分为七层，以及贯穿所有层的治理与可观测能力：

01 交互层       Web / App / 企业 IM / API / Event
02 Agent Gateway 身份、租户、会话、限流、风险分级
03 编排层       Router、Workflow、Planner、State Machine、Approval
04 Agent Runtime Instructions、Skills、Tools、Context、Stop Conditions
05 模型层       Model Gateway、模型路由、结构化输出、预算与降级
06 知识与记忆层 RAG、业务事实、任务状态、用户偏好、版本与权限
07 工具与集成层 Tool Gateway、MCP/API Adapter、CRM/ERP/邮件/数据库

横切能力        IAM、Policy、Audit、Evaluation、Trace、Cost、Safety

图中的关键并不是层数，而是两条边界：

1. 模型不直接访问企业系统。 所有外部动作必须经过 Tool Gateway；
2. 模型不负责授权自己。 是否允许执行由确定性的 Policy Engine 判断。

这两条边界把“一个可能犯错的推理模型”变成“一个被系统约束的业务执行单元”。

二、七层架构怎样设计

Layer 1：Interaction Layer——入口只负责表达目标

入口可以是聊天框，也可以是 CRM 中的“分析客户”按钮、邮件事件、定时任务或其他系统的 API 调用。不要把 Agent 等同于 Chat UI。

交互层负责：

• 收集目标、附件和补充参数；
• 显示执行计划、进度、引用和审批卡片；
• 支持暂停、取消、重试和人工接管；
• 把对外发送、付款、删除等敏感动作明确展示给审批人。

所有入口最后都转换为统一的 TaskSpec，后续系统不应该依赖“用户说了一句话”这种模糊输入。

Layer 2：Agent Gateway——先回答“谁在做什么”

Agent Gateway 类似 API Gateway，但它额外理解 Agent 任务。它必须在模型推理之前完成：

Authentication  你是谁？
Tenant           属于哪个公司或业务单元？
Authorization    能访问哪些数据和工具？
Task Routing     这是客服、销售、采购还是财务任务？
Risk Tier        只读、可逆写入、外部影响还是高风险动作？
Budget           最长运行多久、最多花费多少、最多调用几次工具？

一个可落地的任务契约如下：

{
  "task_id": "tsk_20260807_001",
  "task_type": "sales_region_diagnosis",
  "tenant_id": "acme",
  "actor": { "id": "u_102", "roles": ["sales_manager"] },
  "input": { "region": "east", "period": "2026-Q3" },
  "risk_tier": "L1",
  "budgets": { "max_seconds": 180, "max_tool_calls": 12, "max_cost_usd": 0.8 },
  "acceptance": ["所有数字来自工具结果", "结论包含引用", "不得自动发送邮件"]
}

没有统一任务契约，后面很难做权限、幂等、成本归因和回归评测。

Layer 3：Orchestration Layer——系统真正的控制中心

编排层不是让 LLM 随意思考，而是决定哪些步骤由代码控制、哪些节点允许模型判断。

以“分析华东区销售下降”为例：

1. 校验用户是否有华东区数据权限             deterministic
2. 查询本期与同期销售数据                    deterministic tool call
3. 并行查询客户、产品、渠道和退货维度          parallel workflow
4. 找出显著异常并提出原因假设                  model reasoning
5. 用第二组数据验证每个假设                    evaluator workflow
6. 生成带引用的报告                           model synthesis
7. 发送给区域经理                             human approval + tool call

生产编排器至少需要：

• State Machine：queued → running → waiting_approval → succeeded/failed/cancelled；
• Checkpoint：长任务中断后从已完成步骤继续，而不是全部重跑；
• Idempotency：同一审批回调或写入请求重复到达，不产生双重发送和重复订单；
• Timeout / Retry / Circuit Breaker：区分模型超时、工具暂时失败和永久业务拒绝；
• Human-in-the-loop：审批不是聊天里的一句“可以”，而是一条包含操作者、动作、参数摘要、过期时间的记录；
• Compensation：部分执行失败时，知道如何撤销标签、关闭草稿或回滚状态。

任务路径确定时使用 Workflow；只有无法预先写出路径时才让 Agent 自主选择下一步。这个边界决定系统是否可预测。

Layer 4：Agent Runtime——Agent 到底由什么组成

一个生产 Agent 不是一段 Prompt：

Agent Runtime
= Instructions      角色、目标、边界、完成定义
+ Skills             某类任务的步骤、示例和失败处理
+ Tool Definitions   可调用动作及输入输出 Schema
+ Working Context    当前任务事实、历史步骤、剩余预算
+ Policies           数据、动作和审批规则
+ Evaluators         结果、轨迹和安全检查
+ Stop Conditions    完成、预算耗尽、冲突、连续失败、需要人工

Instructions 应描述稳定原则，Skill 描述可复用任务方法，业务事实从工具实时获取。不要把每天变化的库存、价格和客户状态硬编码到 Prompt。

Runtime 每一轮执行的是同一个闭环：观察状态 → 选择下一动作 → Policy 校验 → 执行工具 → 写入结果 → 判断完成。这个闭环必须有最大轮数和最大工具链长度，避免无限规划。

Layer 5：Model Layer——模型是算力，不是架构

业务代码不应直接依赖某个模型 SDK。Model Gateway 统一处理：

• 供应商与模型路由；
• 超时、限流、重试和故障降级；
• JSON Schema / Structured Output 校验；
• Prompt、模型、采样参数版本记录；
• Token、延迟和费用预算；
• 敏感字段脱敏、允许区域和数据出境策略。

路由策略可以很务实：

“敏感数据使用私有模型”不是完整答案。私有部署仍可能存在日志泄露、越权检索和错误工具调用；公有模型也可能通过零保留、区域部署、字段脱敏和企业契约满足特定要求。安全判断必须围绕数据流，而不是模型品牌。

Layer 6：Knowledge & Memory——不要把向量库叫作企业知识

知识层的基本对象不是 Chunk，而是“有治理的知识条目”：

{
  "document_id": "contract-policy-2026",
  "version": "3.2",
  "owner": "legal",
  "classification": "internal-confidential",
  "allowed_roles": ["legal", "sales-director"],
  "effective_from": "2026-01-01",
  "expires_at": "2026-12-31",
  "source_uri": "s3://knowledge/legal/contract-policy-v3.2.pdf"
}

完整知识链路应该是：

数据源接入
→ OCR / 结构化解析
→ 去重与版本识别
→ 按标题、段落、表格语义切块
→ 继承权限和元数据
→ Embedding + 关键词索引
→ 查询权限过滤
→ Hybrid Search
→ Reranker
→ 返回片段、来源、版本和有效期

Memory 需要分开：

• Working Memory：当前任务中间状态，任务结束后归档；
• Conversation Memory：经过摘要的对话上下文，有长度与生命周期；
• User Preference：语言、格式等明确授权的稳定偏好；
• Enterprise Knowledge：组织政策和业务资料，它不是个人记忆；
• Business State：订单、库存、余额等实时事实，只从权威业务系统读取。

最危险的错误，是把历史对话中的旧事实当成当前业务状态。

Layer 7：Tool Platform——把企业能力变成安全动作

Agent 不应直接生成 SQL 连接生产数据库，也不应拥有“万能 CRM 工具”。正确链路是：

Agent → Tool Gateway → Business API / MCP Server → CRM / ERP / Email / Database

一个工具契约至少包含：

{
  "name": "get_customer_sales",
  "version": "1.3.0",
  "description": "查询指定客户在授权时间范围内的已确认销售额",
  "input_schema": {
    "customer_id": "string",
    "start_date": "date",
    "end_date": "date"
  },
  "required_permission": "sales.customer.read",
  "risk_tier": "L0",
  "timeout_ms": 3000,
  "idempotent": true,
  "audit_fields": ["customer_id", "date_range"]
}

Tool Gateway 负责参数校验、身份透传、权限复核、速率限制、幂等、超时、结果裁剪和审计。模型只看到完成任务所需的最小结果，不能读取整张客户表。

三、一次 Agent 请求到底怎样运行

一次“分析销售下降并把报告发给经理”的完整运行过程是：

1. Gateway 验证用户身份、租户和角色；
2. Router 将任务路由到 Sales Analysis Skill；
3. Orchestrator 创建任务状态、预算和 Trace；
4. Runtime 读取 Skill，只生成当前所需的查询计划；
5. Policy Engine 检查用户能否读取目标区域和指标；
6. Tool Gateway 并行调用 BI/CRM 的窄接口；
7. 工具结果以结构化 Observation 写回任务状态；
8. Agent 基于事实生成原因假设；
9. Evaluator 检查每个数字和结论是否有工具证据；
10. Runtime 生成报告草稿和 send_email 动作建议；
11. Policy 将外发动作升级为人工审批；
12. 审批通过后工具执行，结果进入审计日志和在线评测。

注意：审批发生在动作执行前，而不是模型生成完整回答之后随便弹一个确认框。审批对象必须包含收件人、主题、附件、数据等级和内容摘要，审批后参数被修改则必须重新审批。

四、常用编排模式怎样选

中小企业最常用的不是 Autonomous Agent，而是前三种 Workflow 加少量模型判断。多 Agent 只有在需要上下文隔离、权限隔离、真正并行或独立复核时才值得引入。

推荐的演进顺序是：

Single Prompt
→ Workflow + Tools
→ Single Agent + Skills
→ Supervisor + 2~3 Specialist Agents

不要从最后一步开始。

五、安全治理不是最后加一个过滤器

建议按动作风险定义权限：

生产前至少覆盖以下风险：

• Prompt Injection：网页、邮件、文档均视为数据，不能覆盖系统指令；
• Excessive Agency：工具和数据权限按任务最小化，禁止通配符权限；
• Data Leakage：检索前做权限过滤，日志和模型输入做字段级脱敏；
• Tool Misuse：参数经过 Schema、业务规则和 Policy 三次校验；
• Unbounded Loop：限制轮次、工具链、时间、Token 和费用；
• Memory Poisoning：只有通过验证的信息才能进入长期记忆，并保留来源；
• Supply-chain Risk：第三方 MCP Server 和工具需要固定版本、权限清单与安全审查。

Policy Engine 的输入应是结构化事实，而不是让另一个 LLM回答“这个操作安全吗”。

六、评测与可观测性怎样落到指标

传统 APM 只能告诉你接口是否报错，Agent Observability 还必须回答：为什么选择这个工具、使用了什么知识、是否越权、答案有没有依据、一次合格结果花了多少钱。

建议记录一条统一的 Trace：

task_id
├── input + actor + policy_version
├── route_decision
├── model_call(prompt_version, model, tokens, latency)
├── retrieval(query, filters, document_versions, scores)
├── tool_call(tool_version, args_digest, result_digest, status)
├── approval(actor, action_digest, decision, expires_at)
└── result(evaluation_scores, human_feedback, total_cost)

指标分四组：

评测集不要只放标准问答。它应该包含完整任务：初始状态、允许工具、预期关键步骤、禁止动作、最终验收和可接受的多条路径。模型、Prompt、Skill、工具、知识和 Policy 任一变化，都要跑回归。

七、中小企业可直接采用的部署拓扑

第一阶段没有必要上 Kubernetes。一个稳定的生产起点可以是：

Nginx / Cloud Load Balancer
  ├── Web / Admin Console
  └── Agent API
        ├── Orchestrator Workers
        ├── PostgreSQL：任务、审批、审计、业务配置
        ├── Redis：队列、短期状态、限流
        ├── Object Storage：文档原件和产物
        ├── pgvector / 托管向量库：知识索引
        ├── Model Gateway：模型接入与预算
        ├── Tool Adapters：CRM、ERP、邮件、BI
        └── OpenTelemetry：Trace、Metric、Log

技术选型按复杂度决定：

什么时候才需要拆成平台？当至少三个业务场景重复使用模型网关、工具、知识权限、审批和评测能力，并且独立发布节奏已经互相阻塞。此前保持模块化单体，通常比微服务更可靠。

八、完整落地案例：销售分析 Agent

目标不是“帮销售聊天”，而是把一个明确流程从 2 小时缩短到可控的十几分钟，同时保证所有结论有数据依据。

输入

分析 2026 Q3 华东区销售额下降原因，比较同比与环比，
拆分客户、产品、渠道和退货因素，给出三项行动建议，
生成报告草稿，但不要自动发送。

系统执行

1. Gateway 确认销售经理仅能读取华东区；
2. Router 选择 sales-region-diagnosis:v2 Skill；
3. 编排器并行调用四个只读工具；
4. Agent 找到“大客户流失、A 产品缺货、渠道退货上升”三个候选原因；
5. Evaluator 要求每个原因绑定指标、对比期和查询 ID；
6. 对缺少证据的原因自动补查一次，仍无证据则删除；
7. 输出结论、置信度、数据引用和行动建议；
8. 报告写入内部文档草稿，外发动作等待审批。

验收标准

• 报告中的金额、比例和排名 100% 可追溯到工具结果；
• 不读取华东区之外的客户明细；
• 任一工具失败时明确标记数据缺口，不用模型猜数字；
• 报告生成失败不得触发发送；
• 人工修改被分类为数据问题、推理问题、表达问题或流程问题，并进入评测集。

结果看板

不要预先虚构“效率提升 80%”。上线前冻结基线，上线后按同一口径填入实测结果：

真正的 ROI 应包含模型、工具、基础设施、人工审批、维护和失败成本。最有意义的单位是每个被业务接受的结果成本，不是每百万 Token 价格。

九、90 天实施计划与交付物

0–30 天：跑通一条只读闭环

• 选定一个流程、业务 Owner 和技术 Owner；
• 定义 TaskSpec、三个核心 Tool Contract 和权限矩阵；
• 建立 30–50 条真实任务评测集；
• 完成 Gateway、状态机、Model Gateway、Trace；
• 影子运行，只生成报告，不写业务系统。

交付： 可运行 MVP、基线报告、评测集、风险清单、运行 Trace。

31–60 天：加入知识、审批和有限写入

• 建立文档版本、权限和有效期；
• 增加可逆写入与审批记录；
• 完成 Prompt Injection、越权、超预算、工具失败测试；
• 设置降级、熔断、回滚和一键停用；
• 每周分析人工修改并更新 Skill 与评测。

交付： Knowledge v1、Policy v1、审批流、安全测试报告、质量看板。

61–90 天：对照试点并决定是否扩展

• 新旧流程覆盖至少两个完整业务周期；
• 统计业务、质量、可靠性和经济性四组指标；
• 固化可复用的 Gateway、Tool、Policy、Trace 和 Eval 组件；
• 只有达到验收线才扩大用户和写权限；
• 不达标则定位数据、工具、模型或流程问题，缩小范围而不是继续堆 Agent。

交付： 试点结果、事故预案、运行手册、扩展/停止决策。

十、架构评审清单

• 用户、Agent 和工具是否使用同一套身份与权限上下文？
• 业务事实是否只从权威系统读取，而不是从对话记忆猜测？
• 每个工具是否有 Schema、版本、权限、风险、超时和幂等定义？
• 模型能否绕过 Policy Engine 直接执行动作？
• 外发、资金、删除、合同和生产动作是否在执行前审批？
• 检索是否在召回前做租户与权限过滤？
• 任务中断后能否续跑，重复请求是否会重复写入？
• 是否限制轮数、工具调用、运行时间、Token 和费用？
• 能否通过 task_id 重建模型、知识、工具、审批和结果链路？
• 任一模型、工具或知识源不可用时，系统是否安全降级？
• 是否有离线评测、影子运行、灰度、回滚和一键停用？
• 是否以业务接受结果而不是调用次数衡量价值？

结语

成熟的 Agent 架构不是“一个更强的聊天机器人”，而是一套 AI 原生业务执行系统：模型负责理解与判断，编排器控制流程，知识层提供有权限的上下文，工具层连接真实世界，Policy 决定能不能做，Evaluation 判断做得对不对，Observability 解释整个过程发生了什么。

中小企业不需要从 Agent Marketplace 和 Kubernetes 开始，但必须从清晰边界和完整闭环开始。保留七层逻辑，先以模块化单体实现；用一个真实业务流程跑通，再依据复用、并发和团队边界逐步拆分。

架构的终点不是“拥有多少 Agent”，而是让更多业务任务能够被安全、稳定、可度量地完成。

延伸阅读

• Microsoft：Architecting agent solutions
• AWS：Agentic AI architecture in the enterprise
• OpenAI：A Practical Guide to Building AI Agents
• Anthropic：Building Effective Agents
• Anthropic：Demystifying Evals for AI Agents
• OWASP：AI Agent Security Cheat Sheet
• NIST：AI Risk Management Framework