Steve Sun

如何设计一个智能体（AI Agent）

AI 智能体（Agent）很有可能是未来AI软件设计的范式，所以对于大部分开发者、刚接触 vibe coding 的非技术人员，了解它的设计方式和背后的原理，就能在未来设计新时代的应用软件时更得心应手。

本文试图用通俗易懂的语言，让你理解什么是 AI Agent，它解决了什么问题，以它为基础设施，有哪些协议和工具将在未来派上用场。

本文目标读者：

从第一性原理出发：Agent 框架到底在解决什么问题

模型很强，但不可靠

大模型（LLM）会“猜”，不会“保证”。 所以你不能把它当确定性程序（同样输入一定同样输出）。

需要解决的问题：

现实中的任务结果往往不是一个简单的答复，而是一个完整的流程产出物

真实任务往往是：

这意味着 Agent 的设计目标不仅局限在“一问一答”，而是一套“循环决策系统”。

用户不想等到最后才看到结果

在和AI交互过程中，用户通常希望：

所以系统必须天然支持实时交互，而不是一次性黑盒执行。

上下文会越来越大，成本会越来越高

对话越长，输入越大，速度越慢，费用越高，甚至会超限。 必须有“压缩历史、保留关键信息”的机制。

一个内核要服务多种交互方式

同一个 Agent 要能跑在：

所以"智能内核"和"界面层"必须解耦（彼此独立，不绑死）。

从问题到需求，再到设计

需求清单

一个可用 Agent 框架至少要满足：

  1. 可循环：支持“思考 -> 调工具 -> 再思考”
  2. 可观察：每一步都能被 UI 或日志系统看到
  3. 可控制：能暂停、取消、插队、续跑
  4. 可恢复：失败后可重试，可继续上一次会话
  5. 可扩展：能加新工具、新模型、新前端
  6. 可治理：对成本、上下文、权限有边界

端到端流程图

以问题驱动需求，需求驱动设计的方式，我们就可以得出下面的流程图：

flowchart TD A[用户提出目标] --> B[Agent 理解当前任务] B --> C[是否需要工具?] C -- 否 --> D[直接给出答案] C -- 是 --> E[生成工具调用请求] E --> F[执行工具] F --> G[拿到工具结果] G --> H[结果是否足够?] H -- 否 --> B H -- 是 --> D D --> I[流式返回给用户] I --> J[用户可中断/追加要求] J --> B

这个图表达的是：

整体架构图

graph LR subgraph Interaction Layer[交互层] UI1[TUI/CLI] UI2[RPC/API] UI3[Web/App] end subgraph Runtime Layer[运行时层] SESSION[会话编排器] POLICY[策略中心: 重试/压缩/预算] end subgraph Core Layer[核心层] LOOP[Agent 决策循环] STATE[状态管理] EVENTS[事件总线] end subgraph Capability Layer[能力层] TOOLS[工具系统] MODEL[模型适配层] MEMORY[记忆与上下文管理] end UI1 --> SESSION UI2 --> SESSION UI3 --> SESSION SESSION --> LOOP SESSION --> POLICY LOOP <--> STATE LOOP --> EVENTS LOOP <--> TOOLS LOOP <--> MODEL POLICY <--> MEMORY MODEL --> LLM[外部模型服务]

组件图（理解“谁负责什么”）

flowchart LR USER[用户] ORCH[会话编排器] CORE[Agent Core] ADAPTER[模型适配器] TOOLRUN[工具执行器] OBS[观察与事件] USER <--> ORCH ORCH <--> CORE CORE <--> ADAPTER CORE <--> TOOLRUN CORE --> OBS OBS --> ORCH

职责拆分：

落地这些设计，必备协议和基础设计模式是什么

这一节是完成上面设计的“最小必需品”。需要从协议、设计模式角度考虑引入哪些工程实践。（好比盖摩天大楼，需要先定义好用什么材料、哪些通用的工程设计可以拿来就用、如何让建筑结构从力学上经得起时间验证）。

这些协议目前大部分由开发者按需设计实现，但是在不远的未来，很可能逐个出现标准规范。

必备协议（不全就会失控）

  1. 消息协议（Message Protocol）
  1. 事件协议（Event Protocol）
  1. 工具协议（Tool Contract）
  1. 流式协议（Streaming Contract）
  1. 取消协议（Cancellation Contract）
  1. 错误协议（Error Contract）

需要理解的基础设计模式

对于没有编程经验的读者，下面的一些编程基础设计模式，需要你先从其他资料中理解。

  1. 状态机（State Machine）
  1. 发布-订阅（Pub/Sub，发布与订阅）
  1. 适配器（Adapter）
  1. 策略模式（Strategy）
  1. 管道与过滤（Pipeline）
  1. 幂等与可恢复（Idempotency/Recoverability）

以 PI Agent 为例：设计理念与架构

前面是“通用 Agent 框架设计”。现在落到最近很火的极简框架 PI Agent 。

一起来看看这个框架是如何设计 Agent 的。

设计理念

  1. 内核最小化
  1. 外围可插拔
  1. 过程优先于结果
  1. 会话优先于请求

Agent Core 逻辑流程图

flowchart TD START[开始一次会话回合] --> TURN[开启 turn] TURN --> CALL[调用模型并流式接收输出] CALL --> CHECK{输出里有工具调用?} CHECK -- 否 --> STOPCHECK{是否停止?} CHECK -- 是 --> TOOL[执行工具批次] TOOL --> MERGE[把工具结果写回上下文] MERGE --> STOPCHECK STOPCHECK -- 停止 --> END[结束并发出结束事件] STOPCHECK -- 继续 --> NEXT[进入下一回合] NEXT --> TURN

Agent Core 组件关系图

graph TD CORE[Agent Core] S[State 状态存储] L[Loop 回合循环] E[Events 事件发射] T[Tool Executor 工具执行] M[Model Stream 模型流调用] Q[Queue 消息队列: steer/followUp] CORE --> S CORE --> L L --> M L --> T L --> E L --> Q T --> E M --> E E --> S

这个结构的价值是：

小结

Agent 架构不是“让模型更聪明”，而是“让不确定的模型在可控系统里稳定工作”。

你可以把它记成这个公式：

$$ \text{可用 Agent} = \text{模型能力} \times \text{工程控制能力} $$

其中工程控制能力主要来自：

从目前的趋势看，这大概率将是下一代应用软件的基础范式。

#AI Agent #Agent 框架 #Agent 设计 #PI Agent #智能体架构