如何让企业真正敢把业务交给 AI？生产级 Agent 必备的十二大工程架构底座

看起来会做事，和真正值得托付，是两回事。

近年来，企业界关于 Agent（智能体）的讨论日益热烈。从被视为下一代办公入口，到接入合同、销售、财务等核心系统，演示环节往往惊艳：自然语言指令下，系统能迅速检索、分析并给出建议。

然而，真正的挑战并非在于单次演示的成功，而在于进入日常业务后，Agent 能否在权限、数据、流程和异常面前保持持续可靠。许多隐患在初次运行时并未暴露，直到演变为已签署的合同或已执行的审批时，团队才惊觉：“看起来会做事”与“真正值得托付”之间存在巨大鸿沟。

本文核心看点

某公司法务部门曾遭遇一起尴尬事件：一份被合同审查 Agent 标记为“无风险”的合同，在签署后被发现有特殊折扣条款漏洞。复盘发现，根源在于 CRM 与 ERP 系统中客户名称不一致，导致 Agent 未能检索到该客户的历史风险记录。

此类现象在企业 Agent 落地中屡见不鲜。从 Demo 阶段的惊艳到生产环境的频发问题——权限失控、数据孤岛、流程断点、工具调用失败、缺乏人工确认机制、版本迭代黑盒、归因困难等，团队逐渐意识到：企业 Agent 绝非简单的聊天机器人，其核心竞争力在于模型背后那套复杂的工程系统。

若用公式概括企业 Agent 的本质，可表述为：

核心逻辑在于：模型仅是众多组件之一。决定 Agent 能否从 Demo 走向生产并扛住业务复杂度的，是围绕模型构建的全套工程系统。Anthropic 等业界领先者均建议从最简单的 Prompt 方案起步，仅在需求超出简单方案承载能力时，再逐步引入更复杂的架构。换言之，企业 Agent 是将模型嵌入完整运转的业务系统，而非简单接入。

上述公式可拆解为两类要素：

纵向能力链 (ABILITY CHAIN)

• Prompt：解决“模型听不听得懂”
• Context：解决“模型知不知道”
• Skill：解决“能力能不能被复用”
• Agent：解决“系统能不能自己行动”
• Harness：解决“Agent 能不能稳定运行”
• Loop：解决“系统能不能持续变好”

记忆口诀：听懂 → 知道 → 复用 → 行动 → 稳定 → 进化

横向生产底座 (PRODUCTION BASE)

这六层分别守护：数据可信、语义可懂、业务可流转、效果可测、系统可控、用户可用。以合同审查为例，用户上传合同看似简单，实则同时触发十二套工程协同运作。

Process（业务流程）：管理业务运转逻辑，如节点顺序、责任归属、审批流转及异常补偿。Agent 需在既定业务动线中活动。

Agent（智能执行）：管理具体任务完成，包括目标理解、任务拆解、Skill/Tool 选择及状态判断。这是任务层面的智能。

Harness（运行控制）：管理系统稳定性，涵盖模型路由、调度、注册管理、上下文维护、权限控制、状态持久化、重试熔断及监控成本。这是运行层面的工程。

OpenAI Agents SDK 将追踪、护栏等统一纳入 Agent Runtime，印证了Agent 需要运行控制面支撑的观点。三者关系可概括为：

Process 决定业务怎么走，Agent 决定任务怎么做，Harness 决定整个系统怎么稳。

01 Prompt Engineering：让模型听懂

企业级 Prompt 需明确角色、目标、输入输出 Schema、约束条件及错误处理机制，并从文本升级为包含版本管理的工程资产（Prompt Registry）。评测应聚焦指令遵循率、格式合规率及幻觉率等具体指标。

02 Context Engineering：让模型知道该知道的

Context 不仅包含 RAG，还涉及用户权限、任务状态、长期记忆及数据来源溯源。完善的 Context Runtime 应统一管理检索、记忆、状态、权限、压缩及溯源。

03 Skill Engineering：把“会做”变成“可复用”

Skill ≠ Prompt。Skill = Prompt + Schema + Context + Ontology + Tool + Rule + Permission + Risk + Evaluation + Version。建立 Skill Registry 可避免能力重复建设，实现原子 Skill、复合 Skill 及业务 Skill 的标准化管理与复用。

04 Agent Engineering：让系统真正行动起来

Agent 核心在于 Observe-Think-Act 循环。具备意图识别、任务规划、错误恢复及人工介入能力。建议遵循决策树：单 Agent + Skill 优先，必要时再采用 Multi-Agent 等复杂编排。

05 Harness Engineering：决定 Agent 能否生产化

Harness 处理身份认证、模型路由、权限校验、状态持久化、超时重试及可观测性等问题，是区分 Demo 与生产环境的关键，最终沉淀为 Agent Control Plane。

06 Loop Engineering：让 Agent 越用越好

构建 Feedback → Evaluation → Attribution → Experiment → Version → Canary → Rollback 闭环。强调根因排查而非盲目修改 Prompt，并建立包含模型、Prompt、知识库等在内的整体版本矩阵（Agent Version）。

07 Data Engineering：让 Agent 用上“真”数据

解决数据准确性、时效性及一致性问题。从传统数据平台向 Agent-ready Data 升级，涵盖实体解析、语义层及数据血缘。Data Agent 需兼顾指标口径、权限及事实一致性，远超 NL2SQL 范畴。

08 Ontology Engineering：让企业内部说同一种语言

定义概念、实体、关系及动作语义，解决跨系统术语不一致问题。建议从术语表入手，逐步扩展至业务域本体，最终形成平台级 Business Ontology。

09 Process Engineering：让 Agent 嵌入业务闭环

Agent 价值在于嵌入既有业务流程，形成 Human + Agent + System + Process 协同体，而非取代流程。最终产出为 Process Model。

10 Evaluation Engineering：没有评测就没有工程

分层评测 Prompt、Context、Skill、Agent 等各层级表现，并将 Eval 接入 CI/CD 流程，设立发布门禁。最终沉淀为 Eval System。

11 Safety / Governance：安全不只是 Prompt

构建运行时安全防线：身份认证、数据/工具权限、人工审批、审计留痕及敏感信息脱敏。权限把关应在系统边界硬性执行，而非依赖模型自觉。最终沉淀为 Governance System。

12 Product / UX：决定用户愿不愿意用

避免只给答案不给依据。重点打磨来源引用、执行进度、不确定性表达、人工审批及异常接管能力，建立用户信任。最终沉淀为 Agent UX。

若以十二套工程重构开篇的合同审查案例：Data 层统一客户映射，Ontology 层识别风险条款，Process 层定位审批节点，Context 层准备相关信息，Prompt 层明确任务，Skill 层执行分析，Agent 层规划动作，Harness 层管控权限与状态，Safety 层拦截高风险并要求人工确认，Product 层展示依据，Evaluation 层记录结果，Loop 层沉淀反馈。由此，Agent 在每次交互中进化为更可靠的系统。

1. 选场景：聚焦高频重复业务痛点。
2. 跑通单 Agent：完善 Prompt、Context、Skill、Agent 四层。
3. 接入 Harness：补全身份、权限、监控等运行时能力。
4. 建立 Evaluation：搭建数据集与评测门槛。
5. 建立 Loop：形成反馈与迭代闭环。
6. 补齐底座：逐步完善 Ontology、Process、Data 等企业级基础。
7. 平台化：最后考虑 Multi-Agent 协作及 Agent Platform 建设。

MCP 与 A2A 协议虽为未来基础设施，但不应作为起步重点。

企业 Agent 的终局并非无所不能的超级个体，而是一套成熟的数字执行系统。六条纵向能力链乘以六层横向工程底座，共同构成真正的“企业级 Agent Operating System”。

附：企业 Agent 工程检查表