实用主义的设计，将“演示型 Agent”转变为可靠的产研构建者——更少的幻觉、更紧密的闭环、更实在的成果。

八种可用于生产的 AI Agent 架构，附带代码片段与实战经验——规划器-执行器、路由分发、有限状态机（FSM）以及基于工作流的 Agent。

你见过不少 Agent 承诺上天入地，结果却在起跑线上就卡住。真正能交付的关键不在于模型更大，而在于结构——清晰的目标、确定性的工具，以及能闭环的反馈机制。以下这八种架构，是我亲眼见证过能持续推动任务进入“已完成”状态的方案。

1) 单一 Agent + 确定性工具（“锋利的凿子”）

一个轻量级的 Agent，只调用少量经过验证的工具：搜索、数据库查询、代码生成到沙箱、工单更新等。没有花哨功能，推理路径清晰、快速。

适用场景

• 领域明确、API 清晰。

• 有 SLA 要求，需要可预测性。

生产提示：遇到未知工具立即失败；记录每次工具调用的输入/输出，便于重放。

2) 规划器–执行器（ReAct，但更成熟）

规划器制定步骤；执行器在严格工具契约下执行操作。一个轻量级的验证器检查世界是否按预期发生了变化。

为何能交付

• 规划与执行需要不同的提示词和温度设置。

• 可以更换规划器而不影响工具实现。

实战经验：添加自动“修复”步骤——如果后置条件失败，规划器会收到差异信息并再尝试一次。

3) 路由器 + 专业技能 Agent（分发，而非争论）

一个路由器模型对用户意图进行分类，并路由到微型 Agent（如 SearchAgent、SQLAgent、CodeFixAgent）。每个专业 Agent 规模小、可测试，仅配备 3–7 个工具。

为何能交付

• 有效遏制范围蔓延。

• 故障局部化，不会引发系统性崩溃。

生产提示：当路由器置信度较低时，保留一个安全默认路径（例如“仅从文档中回答”）。

4) 有限状态机 Agent（减少意外）

将工作表示为状态：DEFINE -> PLAN -> EXECUTE_STEP -> VERIFY -> REVIEW -> DONE/FAIL。状态转换需满足守卫条件并设置超时。

为何能交付

• 无隐藏循环；每一步跳转都可观测。

• 在受监管团队中，审计性极佳。

from enum import Enum
class S(Enum): DEFINE=1; PLAN=2; EXEC=3; VERIFY=4; REVIEW=5; DONE=6; FAIL=7
state=S.DEFINE
while state not in {S.DONE,S.FAIL}:
    if state==S.DEFINE: goals=llm(...); state=S.PLAN
    elif state==S.PLAN: steps=llm(...); state=S.EXEC
    elif state==S.EXEC: out=run_step(...); state=S.VERIFY
    elif state==S.VERIFY: state = S.REVIEW if check(out) else S.PLAN
    elif state==S.REVIEW: state = S.DONE if approve(out) else S.PLAN

5) 基于工作流的 Agent（Temporal/Cadence/Airflow）

使用一个健壮的编排引擎处理重试、定时器、幂等性和补偿逻辑。Agent 是大脑，工作流引擎则是神经系统。

为何能交付

• 崩溃后仍能持久化重试。

• 人工介入步骤是一等公民（支持暂停、SLA 等）。

实战经验：将工具调用记录为事件；天然支持重放和时间旅行式调试。

6) 评论家–编辑器配对（两个小模型胜过一个大模型）

编辑器提出修改方案；评论家强制执行约束条件：测试通过、代码风格、安全检查、引用来源等。若评论家不通过，编辑器会收到结构化反馈并再次尝试。

为何能交付

• 将“感觉”转化为规则。

• 在代码、知识问答和 SQL 任务中效果显著。

patch = editor(repo, issue)
report = critic(patch, checks=["tests","lint","migrations"])
if not report.passed: patch = editor(repo, issue, feedback=report.errors)

生产提示：确保评论反馈是机器可读的（JSON 格式），以便编辑器能确定性地响应。

7) 事件驱动型 Agent（订阅、检测、行动）

Agent 订阅领域事件——如错误激增、作业失败、客户流失信号。它们不轮询，而是响应：分类、生成修复 PR、起草沟通文案、安排后续跟进。

为何能交付

• 大幅缩短平均响应时间。

• Agent 在无事件时保持空闲（成本低）。

实战经验：搭配小型预案使用，例如：“若 500 错误↑ 且最近 30 分钟有部署，则回滚 + 创建事件工单。”

8) 带记忆的 RAG 产品 Agent（基于上下文决策，引用来源）

将 Agent 与精选检索索引结合：产品规范、历史工单、操作手册、法律条款等。每个回答都包含引用；当上下文不足时，拒绝回答并创建研究任务。

为何能交付

• 将幻觉降至可接受水平。

• 新成员入职第一天就能利用机构记忆。

生产提示：按新鲜度拆分索引（如变更日志 vs PDF 文档）；生成前加入重排序器，并要求至少两个来源一致。

一个微型端到端骨架（带审核的规划器–执行器）

class ToolError(Exception): ...

TOOLS = {...}  # 确定性函数

def agent_ticket_runner(ticket):
    goal = llm(f"Define success for: {ticket.title}\nReturn JSON {{'ok':bool,'definition':str}}")
    ifnot goal['ok']: return"Need clarification"
    for _ in range(3):  # 限定尝试次数
        plan = llm("Make numbered steps with required tools only", tools=TOOLS.keys())
        results = []

        for step in plan['steps']:
            tool = TOOLS.get(step['tool'])
            ifnot tool: raise ToolError(step['tool'])
            results.append(tool(**step['args']))
        # 自动验证
        verify = llm(f"Given results {results}, did we meet: {goal['definition']}? true/false")
        if verify isTrue:
            url = TOOLS["open_pr"](changes=results[-1])
            returnf"Proposed fix in PR: {url}"
    return"Escalated to human reviewer with logs attached"

这样做的好处

• 限定循环次数、工具白名单、后置条件检查。

• 在 open_pr 前可统一插入人工审批环节。

真实世界快照

• 内部平台团队：采用“路由器 + 评论家–编辑器”架构，将 Bug 修复中位时间从 2.4 天缩短至 10 小时。关键突破在于幂等工具和评论家强制执行的 PR 检查。

• 客服自动化：带记忆的 RAG Agent 为每个回答引用两份文档，遇到未见过的问题则拒绝回答。升级率下降 31%，用户信任度提升，因为每个主张都有据可查。

• 增长运营：事件驱动 Agent 监控支付错误。一旦出现激增，自动重放日志、起草状态更新、并打开回滚 PR。平均缓解时间从 43 分钟降至 11 分钟。

比模型大小更重要的防护机制

• 契约优先：工具必须有明确 Schema，Agent 不能传递意外参数。

• 时间与预算限制：最大步骤数、最大 token 数、显式成本上限。

• 可观测性：记录提示词、工具输入输出、状态转换，并配套监控看板。

• 人工关卡：在不可逆操作前（如删除、开票、部署）设置审批。

• 冷路径处理：当置信度低时，安全回答或创建研究任务。

如何选择你的首个架构

如果你从零开始，建议选择规划器–执行器或路由器 + 专业 Agent。它们可组合、易调试。当你需要长期可靠运行时，将其封装进工作流引擎。对于安全敏感任务，加入评论家，并将其视为 CI 流程的一部分。而当回答必须可信时，结合带记忆的 RAG 并强制引用来源。

说到底：最难的部分从来不是“智能”，而是管道、契约和防护机制。把这些做好，即使是中等规模的模型，也会显得出奇地强大。