更多 AI 文章见《智周万物（AI集萃）》专栏
AI Agent（智能体）是一种能够自主感知环境、做出决策并执行复杂任务的智能实体：以大模型为核心、具备感知 - 规划 - 执行 - 反思闭环能力 。
原理
AI Agent 的本质则是把大模型作为核心控制器（CPU），采用"目标-推理-反馈"的认知闭环（Cognitive Closure），具备了极高的环境韧性（Resilience）：
- 根据用户输入，系统被赋予的是一个模糊或具象的终极目标（Goal）
- 以 LLM 作为计算核心，语义理解、常识推理和上下文演化能力，将目标拆解为任务树
- 运行时（Runtime）根据外部环境的即时反馈（Feedback）动态生成并修正解决路径。
根据 Andrew Ng 的总结及工程实践，以下四种默认构成了 Agent 的基石。
反思模式 (Reflection)
从"自我纠错"到"环境感知闭环"；早期的反思纯粹依赖 LLM 的"左脑审判右脑"（同一模型自身拆分两套思维，一侧生成回答，另一侧评判纠错，自己校验自己 ），极易引发共生幻觉（Shared Hallucination）。
环境内生反思 (Environment-in-the-Loop Reflection)"------将确定性的编译器、静态分析工具（Linter）或单元测试框架作为 Critic（裁判），与 LLM（Actor）构成闭环。
典型的 Actor-Critic（执行者-评论者） 或 Reflexion 架构：
- 空间换时间/成本：反思会导致调用链呈 O(N) 线性增长，延迟（Latency）显着放大。
- 熔断设计：在工作记忆中硬编码
max_reflection_attempts计数器（通常设为 3~5 次）;一旦触顶，必须强制中断并降级抛出异常，防止 Token 遭遇无限循环消耗（Token Runaway）。
工具使用模式 (Tool Use)
从"自主发现"到"协议标准化（MCP）"；大模型直接野蛮调用原生 API 的时代已过去，主流采用 MCP（Model Context Protocol，模型上下文协议） 以及大模型厂商内建的 Native Function Calling。
大模型不直接执行工具，而是一个指令翻译器：
- 大模型根据任务，输出特定 Token（如 JSON 格式的
tool_calls）。 - Agent 运行时引擎（Runtime）拦截该 Token，解析出函数名与参数。
- 运行时引擎在隔离沙盒中执行物理调用，并将结果包装为
tool_response塞回大模型的上下文窗口。
工程实践：
- 沙盒隔离 (Sandbox Isolation)：执行代码解释器（Code Interpreter）或 Shell 命令，必须在绝对隔离的轻量化沙盒（如 Docker、gVisor 或 WASM 运行时）中，防止 Prompt 注入攻击引发主机权限提升或删库。
- 防重入与幂等性 (Idempotency)：因为网络抖动对某个支付或数据库写入工具调用了两次，必须实现幂等。
协议交互与数据约束
标准 MCP 或 Function Calling 中，其核心数据流由严谨的 JSON Schema 约束。典型的工具调用生命周期包含以下两个核心载荷（Payload）：
- 工具调用请求（LLM➡️Runtime）
plain
{
"id": "call_mcp_9a8b7c",
"type": "function",
"function": {
"name": "execute_secure_query",
"arguments": "{\"table\": \"production_logs\", \"limit\": 5, \"filter\": \"status='ERROR'\"}"
}
}- 执行后上下回填（Runtime➡️LLM）
plain
{
"role": "tool",
"tool_call_id": "call_mcp_9a8b7c",
"name": "execute_secure_query",
"content": "{\"status\": \"success\", \"data\": [{\"timestamp\": \"2026-05-24 09:15:00\", \"error_code\": \"ERR_503\", \"msg\": \"Service Unavailable\"}]}"
}规划模式 (Planning)
从"线性 CoT"到"状态图路由与搜索"。简单的思维链（CoT）或纯 ReAct 模式由于逻辑过于发散，在生产环境中故障率高。当前主流采用"状态图路由（State-Graph Routing）"与"类 MCTS（蒙特卡洛树搜索）隐式规划"。
- 静态规划（Plan-Then-Solve）：适用于确定性高的复杂任务（如标准报表生成），被物化为确定的 DAG（有向无环图）工作流。大模型先生成一个包含多个 Task 节点的 Task Tree，随后由底层的 Task Executor 并行或串行驱动。
- 动态规划（Stateful Routing）：采用类似 LangGraph 的图架构，由图结构中的条件边（Conditional Edges）和路由大模型共同控流。。每一步执行完毕后，由一个轻量级的 Router LLM 检查当前的系统状态（State），并决定下一条跳转的边（Edge）指向哪里。
推理范式与图搜索
针对高模糊度、高容错要求的任务，Agent 运行时会将控制流升级为类 MCTS（蒙特卡洛树搜索）或思维图（GoT）拓扑。在这种模式下，规划不再是简单的条件跳转，而是一个离散的搜索树状态演进过程：
plain
[当前状态 S0] ── 提示词分叉 (Expansion) ──► [生成候选路径 A] ── 运行 Critic/评估 ──► 评分: 0.82 (保留)
──► [生成候选路径 B] ── 运行 Critic/评估 ──► 评分: 0.21 (剪枝)- Selection（选择）：从当前工作记忆的状态树根节点出发，依据过往反思日志的累积权重，选择最优的子任务边界。
- Expansion（扩展）：以大模型为发生器，围绕当前任务节点并行生成 N 种不同的解题路径或子 Prompt 分支（类似思维树 ToT 的多分支派生）。
- Simulation/Evaluation（模拟与评价）：引入确定性的启发式规则或专用的 Value LLM（价值模型）对这些分支进行评估，计算状态评价值V(s)。
- Backpropagation（回溯与剪枝）：将评测得分反向更新至父节点状态。对于低于硬熔断阈值的路径，在有向无环图（DAG）中直接进行物理"剪枝"，从而在动态变异中规避因逻辑发散产生的无限路径漂移。
多智能体协作模式 (Multi-Agent Collaboration)
从"聊天室聊天"到"黑板模式工作流"。早期的多智能体（如 AutoGen 早期版本）让几个 Agent 在一个公开 Chat 里面盲目群聊，Token 消耗呈指数级爆炸，且极易产生信息污染。当前主流模式是"基于黑板架构的 SOP 流水线（Blackboard-based SOP Workflow）"。Agent 之间不直接对话，而是通过读写一个共享的中央状态对象（Shared State / Blackboard）来协同工作，类似于标准的现代工厂流水线。
- 角色特异性（Role Specialization）：不同的 Agent 被注入不同的 System Prompt（如 Coder 只有编码常识，Tester 只有黑盒测试方法论）。通过缩小单一 Agent 的职责边界，大幅降低了模型的困惑度（Perplexity），从而将幻觉率降低了 80% 以上。
- 通信拓扑：星型架构（由一个 Supervisor Agent 调度所有 Worker）或流水线架构（Agent A →Agent B →Agent C）。
- 状态一致性保障：在多 Agent 并发读写黑板（Blackboard）时，为防止数据覆盖与状态竞争（Race Conditions），运行时引擎必须实现类似数据库快照隔离（Snapshot Isolation）或悲观锁机制。每一个 Agent 在认领其对应 SOP 阶段的任务时，必须通过原子的检查点机制（Checkpoint Check）对其专属的工作记忆分片进行互斥锁定。
现代 Agentic 统一编排
生产环境中应用这四种模式时，它们不是孤立存在，而是交织成一个高度弹性的系统：
| 层次 | 核心组件 | 说明 |
|---|---|---|
| Orchestration (编排层) | Stateful Graph Engine | 负责规划与多智能体协作。通过统一的状态图（State Graph）管理多个 Agent 的执行序列。 |
| Context & State (状态层) | Working Memory Hub | 负责管理 Agent 协作期间的全局状态。采用 Redis 或内存数据库，提供事务一致性与检查点（Checkpoints）能力，支持断点续传。 |
| Integration (集成层) | MCP Gateway / Tool Registry | 负责工具使用。充当工具的网关，处理类型安全校验（Pydantic Schema）、超时控制（Circuit Breaker）和安全审计。 |
| Compute (计算/内核层) | Domain-Specific LLMs | 负责反思与核心推理。根据任务不同选择不同的模型（如规划层用长上下文推理模型，反思/校验层用轻量、低延迟模型）。 |
架构
真实的工程落地中，Agent 不再是一个单一的 Prompt，而是解耦职责清晰的软件模块：
- 感知模块 (Perception) ------ 管道与门面模式：将数字或物理世界的多模态输入（文本、截图、网关日志、结构化数据库、API 返回值）统一清洗、升维，并转化为 LLM 能够理解的标准化 Token 序列（
StandardInputMessage）。 - 记忆系统 (Memory) ------ 状态与事务管理：必须管理好三种跨度的记忆：
- 短期记忆（Short-term）：当前会话的上下文窗口（Context Window），维系聊天的连贯性。
- 长期记忆（Long-term）：依赖外部向量数据库（Vector DB），通过语义相似度检索，提供业务域的硬性规则、用户画像以及历史成功案例。
- 工作记忆（Working Memory）：最核心的工程组件；本质是一个具备强 Schema 约束的任务状态机（State Object），精确记录了当前任务走到第几步、中间变量的值是多少、上一步工具调用的返回结果等，支持系统的断点续传（Check-pointing）。
- 规划模块 (Planning) ------ 策略与推理模式：大脑的核心计算部分；不使用固定的代码路径，而是通过不同的推理范式（如思维链 CoT、思维树 ToT、思维图 GoT）把宏观目标拆解为有依赖关系的任务树/有向无环图（DAG）。
- 工具调用模块 (Tool Use) ------ 注册表与适配器模式：Agent 的"双手"；大模型本身不具备直接操作现实世界的能力，工具调用模块作为一个注册中心（Tool Registry），将原生代码函数或 OpenAPI 规范抽象并翻译为模型可识别的配置。当大模型输出
tool_call命令时，该模块通过反射机制完成真正的底层物理调用。 - 执行与反馈模块 (Action & Feedback) ------ 运行时事件循环：Agent 的主外壳（Runtime Engine）；通常是一个鲁棒的
while事件循环，负责管理 Token 预算消耗、拦截非法命令、捕获执行异常、以及处理人工介入审批（Human-in-the-loop）的中断流。
运行时主核心示例
为防止静默失败（Silent Failure）并确保生产环境的鲁棒性，以下是一个生产级运行时引擎核心事件循环伪代码。采用 Pydantic 进行输入/输出校验，并在各阶段加入了硬熔断与严谨的防御性异常处理机制：
python
import logging
from typing import Dict, Any, Optional
from pydantic import BaseModel, Field
# 初始化生产日志组件
logger = logging.getLogger("agent.runtime")
class AgentState(BaseModel):
task_id: str
goal: str
current_step: int = 0
working_memory: Dict[str, Any] = Field(default_factory=dict)
is_completed: bool = False
class RuntimeEngine:
def __init__(self, llm_client: Any, tool_registry: Any, max_loops: int = 5):
self.llm = llm_client
self.tools = tool_registry
self.max_loops = max_loops # 强制硬熔断计数器限制
def execute_loop(self, state: AgentState) -> AgentState:
"""
核心PPER (Sense-Plan-Execute-Reflect) 运行期事件循环
"""
logger.info(f"Initiating agentic runtime for Task {state.task_id}. Goal: {state.goal}")
while not state.is_completed:
# 防御性防御 1: 路径漂移与死循环熔断
if state.current_step >= self.max_loops:
logger.error(f"Execution aborted. Task {state.task_id} breached Max_Loop_Count limit ({self.max_loops}).")
raise RuntimeError("Token Runaway Protection: Maximum reflection/planning loops exceeded.")
state.current_step += 1
logger.info(f"Loop iteration execution started. Step: {state.current_step}")
try:
# 1. Sense & Plan: 结合上下文与工作记忆驱动大模型
llm_response = self.llm.generate_plan(
goal=state.goal,
memory=state.working_memory,
step=state.current_step
)
# 检查是否达成最终目标
if llm_response.get("status") == "FINAL_RESPONSE":
state.working_memory["final_output"] = llm_response.get("content")
state.is_completed = True
break
# 2. Execute: 工具调用拦截与参数 Pydantic 强校验
tool_call = llm_response.get("tool_call")
if tool_call:
tool_name = tool_call["name"]
tool_args = tool_call["arguments"]
# 拦截高危动作，引入 Human-in-the-Loop 审批挂起
if self.tools.is_high_risk(tool_name):
logger.warning(f"High-risk action detected [{tool_name}]. Suspending state machine for manual approval.")
# 生产环境通常在此处持久化 Checkpoint 并挂起，等待人工确认信号
human_approved = self._await_human_intervention(state.task_id)
if not human_approved:
raise PermissionError("Action rejected by human supervisor.")
# 在隔离沙盒执行物理调用
logger.info(f"Invoking verified tool: {tool_name}")
observation = self.tools.invoke_in_sandbox(tool_name, tool_args)
# 3. Reflect: 强制反馈数据写入工作记忆，用于下一轮迭代决策
state.working_memory[f"step_{state.current_step}_obs"] = observation
logger.info(f"Step {state.current_step} observation committed to working memory.")
else:
# 模型既没有给出结果也没有调用工具，属于异常推理状态
raise ValueError("Model fallback: Failed to generate both valid tool action and final response.")
except Exception as e:
# 防御性异常捕获：杜绝静默失败，执行原子的 Checkpoint 状态持久化并向上抛出
logger.critical(f"Execution cycle failed at step {state.current_step}. Stack-Error: {str(e)}")
self._checkpoint_atomic_state(state)
raise e
# 每个循环结束，原子化持久化中间变量，支持断点续传
self._checkpoint_atomic_state(state)
logger.info(f"Task {state.task_id} successfully accomplished.")
return state
def _checkpoint_atomic_state(self, state: AgentState) -> None:
# 生产环境中在此处将 state 序列化并写入高可靠持久化层（如 Redis 或分布式 DB）
pass
def _await_human_intervention(self, task_id: str) -> bool:
# 人工审批桩函数
return True生命周期流程
Agent 启动后，其运行期（Runtime）的数据流会严格按照 感知（Sense）- 规划（Plan）- 执行（Execute）- 反思（Reflect） 的闭环顺序循环流转，直至目标达成或预算耗尽 。
详细步骤拆解：
- 感知 (Sense)：捕获环境状态变化。
- 规划 (Plan)：大脑（LLM）结合当前环境、短期记忆与工作记忆，评估当前所处的任务节点，决定下一步是继续拆解任务、调用具体工具，还是直接输出结果。
- 执行 (Execute)：执行层接管大模型的
tool_calls指令，安全地驱动外部工具。环境受工具影响发生改变，并返回硬性的执行反馈。 - 反思 (Reflect)：大脑接收到工具执行的硬性反馈后，进行一轮自我审判（如：代码为什么编译报错？API 为什么返回 403？）。反思做出的纠错结论会立即写回工作记忆（Working Memory）。在下一个循环的"规划"阶段，大模型将基于这个更新后的工作记忆调整策略，从而避免在同一个错误上死循环。
工程准则
在生产环境中落地上述架构与流程时，必须遵守以下硬核工程准则：
| 潜在风险 | 架构防御手段 (Guardrails) |
|---|---|
| 路径漂移与死循环 | 1. 禁用纯动态规划，改用 Plan-Then-Solve 输出任务树； 2. 框架层强制设定 Max_Loop_Count（最大循环上限），超限立即熔断报错。 |
| 幻觉导致越权或删库 | 1. 执行层引入强制类型校验（如 Pydantic）与 AST 静态代码解析； 2. 工具链部署在高隔离的沙盒环境（如 Docker / gVisor）中，实施最小权限原则。 |
| 网络抖动或 Crash 导致状态丢失 | 记忆系统必须具备分布式事务属性（Unit of Work）。每一个 PPER 循环完成后，必须将工作记忆（State）原子化地持久化到 Redis 或 DB。系统 Crash 后，通过读取最新的 Checkpoint 实现断点续传。 |
| 不可逆的关键动作失控 | 引入 Human-in-the-Loop（人工介入审批机制）。当 Agent 规划的下一步动作涉及资金变动、生产环境发版等高危行为时，执行层自动挂起（Suspend），等待人工确认后再唤醒状态机。 |