我最近在网上看到一套"Agent 的 12 种核心构建范式"，感觉它实际上很明确的介绍了AI Agent如何从一个演示程序到生产可用的搭建过程和原则。挺完整，就顺手记录、翻译了一下，也补了一点自己在工程视角下的理解。
现在很多 Agent 的现状是：
重原型、轻生产。能跑起来、能演示，能干的事情更多是写 PPT、写报告、做个工具小助手，但一到生产就露馅：不稳定、不可控、不可追溯、难扩展。
如果把 Agent 当成"分布式系统的一种新形态"，那它就得像分布式系统一样被治理：可观测、可回滚、可控、可扩展、可协作。
下面这 12 条，我更愿意把它当成一套"从原型到生产"的工程化骨架。
1）自然语言 → 工具调用的精准转换
Agent 的价值不是"会说"，而是"能把事情做完"。但问题在于自然语言天然模糊，必须把意图变成明确的动作、参数、输出格式，而且过程要可追溯。
示例：
老板说"给我上周销售情况"。
原型式 Agent 可能只回"上周 123 万"。
生产式 Agent 会：查数据仓库 → 分渠道/区域/日期聚合 → 输出 Excel/图表 → 附上查询条件与数据来源，出问题能定位到哪一步。
工具有很多种，比如：飞书消息，邮箱，高铁12306订票。自然语言必须要能准确描述工具的调用。
关键点：
整个"理解-拆解-调用-合成"的过程必须清晰可追溯。如果最终表格数据错了，你能快速定位是哪个工具调用出错，还是理解偏差。
2）提示词可自定义、可追溯（提示词要版本化）
提示词是灵魂，但灵魂不能写死在代码里。提示词必须做到：可配置、可回滚、可审计，最好有提示词库与版本管理。
示例：
客服 Agent 的提示词经常因行业，政策、合规、措辞调整而变化。
线上效果变差时，如果没有版本，就只能猜；有版本管理才能灰度、对比、回滚。不断迭代或者撤回。
关键：
不同行业、不同场景的提示词千差万别，把它从代码里剥离出来，变成可动态调整的"参数"，是迭代和优化的基础。
3）主动管理上下文窗口（记忆分层 + 压缩 + 淘汰）
LLM 没有真正记忆，上下文就是"临时记忆"。不能只设一个窗口长度让它溢出，而是要主动管理：筛选、压缩、打分、分层保留，避免关键事实丢失。
示例：
合同审阅中早期约束"付款必须月结"是硬规则。
上下文溢出把它丢了，后面总结就可能写成"预付"。
工程上要把硬约束放进"不可丢失层"，过程讨论可压缩，闲聊可淘汰。
关键：
可以设计评分机制，对上下文中的信息块进行重要性评级，动态淘汰低分项，保留高分项，防止关键信息丢失。确定哪些信息是不可丢弃的和非重要的。
4）工具调用是一种结构化输出（由模型选择工具与参数）
不要让模型输出一段自然语言，再靠代码猜"它想调用哪个工具"。正确姿势是：工具调用本身就是结构化输出（例如 JSON schema），模型明确指定工具名和参数。
示例：
"订明天下午去深圳高铁票"：
结构化输出会明确：先 search 再 book，参数包含时间窗、座位偏好、乘客信息。
这样工具层只负责执行，LLM 负责决策与生成指令，天然解耦。
关键：
需要将 LLM（负责理解与规划）与执行器（负责调用工具）的解耦，让架构更清晰、更易维护。
5）统一执行状态与业务状态（全局状态一致 + 幂等可恢复）
Agent 的执行是多步的，同时业务系统有数据库状态。两套状态不一致会导致：重复提交、丢单、回滚不了、重启后不知道做到哪了。
所以要把 Agent 的执行状态与业务状态统一成一个全局状态模型，保证一致性与可恢复性。
示例：
报销流程"提交审批"成功后 Agent 崩了。
重启不能再提交一次。所以，全局状态要记录"已提交"的事实，后续恢复时，可以精准恢复上次的状态。
关键：
保证数据一致性，是实现Agent执行可中断、可恢复（容错）的基石。
6）标准化 API 管理生命周期（可自动化、可管控）
生产里不能靠"某个网页点按钮"管理 Agent。需要用标准化 API 管理生命周期： 所有的调用都要API化，保证可自动化。
示例：
夜里批处理失败。
监控告警 → 自动 pause(run_id) 防止扩散 → 生成摘要给 oncall → 修复后 resume 或 retry(step)。其中每个步骤都要有可调用的API，这才是生产环境的正确做法。
关键：
这是将Agent纳入现代化运维体系、实现自动化弹性伸缩的前提。
7）主动式人机协作（人不在线也能跑）
现实任务经常需要人确认，而且人未必在线。Agent 要能主动发起协作：通知、询问、等待、超时、升级处理。
示例：
采购 Agent 做完比价，需要经理确认最终供应商。
Agent 发 IM 卡片：报价对比 + 推荐 + 风险点 → 等点击同意/驳回 → 超时提醒或升级给代理人。
关键：
将人纳入任务的回路中，在关键节点增加可控性，处理AI无法独自决定的复杂情况。
8）自主控制执行流程（用状态机承载分支与判断）
真实流程分支很多，复杂逻辑靠固定工作流很难覆盖干净。更稳的做法是：定义状态机（状态集合 + 转移条件 + 每个状态的动作）。
示例：
工单处理状态机：
NEW → CLASSIFIED → NEED_INFO → WAIT_USER → IN_PROGRESS → RESOLVED → CLOSED
每个状态有固定责任：提问、等待、诊断、输出证据、请求确认。
这样复杂流程才可控。
关键：
赋予Agent基于当前状态和上下文进行自主决策和控制流程的能力，以应对现实的复杂性。
9）错误信息精简压缩（把"可推理信息"给模型）
出错时把全部日志丢给大模型，基本等于制造噪声。模型容量有限，要用模板把错误压缩成最少必要信息。
示例：
日志压缩成固定格式：
错误码 / 请求 URL / 关键参数 / traceId / 上下游依赖 / 重试次数 / 影响范围 / 下一步建议
把"可推理的核心信息"留给模型。
关键：
保护宝贵的上下文窗口，让LLM专注于业务逻辑决策，而非解析混乱的错误日志。
10）小而专注的 Agent（多 Agent 协作比全能更可维护）
全能 Agent 会导致提示词越来越长、工具越来越多、行为越来越不可控。拆成多个小 Agent，通过 A2A 协作，维护成本会显著下降。
示例：
财务月结拆成四个 Agent：
DataAgent 拉取校验 → ReconAgent 对账解释 → ReportAgent 生成报表解读 → ApprovalAgent 发起确认留痕。
每个 Agent 更可测、更可控，也更容易替换升级。
关键：
极大降低单个Agent的复杂度和维护成本，提高系统整体的鲁棒性和可复用性。
11）全链路触发与集成（嵌入现有系统，不要另起交互入口）
好的 Agent 不该强迫用户换入口、换习惯。越"另起炉灶"越难推广。应该嵌入已有环境：IM、工单、CRM、OA、浏览器、IDE。
示例：
运维 Agent 直接在告警系统里触发：
告警 → 一键诊断 → 拉日志/指标 → 输出结论并回写工单。
不需要再打开一个"聊天网页"，保存原有使用习惯。
关键：
降低使用门槛，让AI能力在用户现有的工作习惯和环境中自然浮现，这是提高采纳率的关键。
12）无状态服务设计（请求自包含 + 外置状态支撑横向扩展）
要上生产就得支持并发与扩缩容。无状态设计意味着：每次请求携带所需信息，请求之间相互独立；状态放到外部存储或状态服务中。
示例：
客服高峰期上千会话。
如果会话状态在内存里，重启/扩容就丢。
无状态把会话与执行状态放在外部（也呼应第 5 条），任何实例都能接手，系统才能高可用。
关键：
这是互联网服务架构的黄金法则，确保了Agent服务的高可用性、弹性伸缩能力和故障恢复能力。
这就是12个范式的讲解，你可以看到，这并不是什么AI知识，基本上属于软件工程的范畴，但如果不按这样做，你很难将Agent应用到生产环境。
我们来回顾一下12个范式，再强调一下，它们是一套体系，不是 12 条孤立建议。
这 12 条我更愿意当成一套"生产架构"：
举例：
• 12 依赖 5：要无状态扩展，就必须有统一全局状态，否则很难实现。
• 11 依赖 1：要嵌入业务系统，最终都要落到 "自然语言→工具调用"
• 9 支撑 8：状态机要稳定运行，错误输入必须可控、可推理
• 10 降低整体复杂度：拆分后提示词、评测、权限、工具都更容易治理
一句话：从 Demo 到生产，核心不是"更聪明"，而是"更可控"，要有工程化处理。
我理解的落地路线：从能跑 → 可控 → 可扩展
如果把建设分阶段（偏工程视角），大概是：
第一步：能跑
先把 1 和 4 做扎实（自然语言→结构化工具调用）
第二步：可控
把 2/3/5/6/9 补齐（提示词版本、上下文管理、全局状态、生命周期 API、错误压缩）
第三步：可扩展
上 10/11/12（拆分协作、全链路集成、无状态扩展）
同时把 7/8 作为"从业务试点走向稳定生产"的关键补强（人机协作 + 状态机流程）。
好了，你可以理解12范式就是将Agent生产化的方法论。