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

Tue, 26 May 2026 16:11:00 +0800

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

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

本文目标读者：

Vibe coding 人群（快速做原型、边做边改）
程序员
刚接触编程的非技术用户

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

模型很强，但不可靠

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

需要解决的问题：

如何让不稳定输出进入可控流程
如何在失败时知道失败在哪里

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

真实任务往往是：

读信息
做决策
调用工具
根据工具结果继续决策
最终产出文档、代码或者其他

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

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

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

过程可见（streaming，流式显示）
可以打断（abort，中止当前任务）
可以中途追加指令（steer，在执行任务过程中给予引导）

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

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

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

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

同一个 Agent 要能跑在：

终端界面（TUI，Terminal UI，终端交互界面）
远程调用（RPC，Remote Procedure Call，远程过程调用）
未来可能的 Web 或 App

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

从问题到需求，再到设计

需求清单

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

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

端到端流程图

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

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

这个图表达的是：

Agent 是闭环系统，不是单次函数。
“工具”是能力放大器，不是附属品。
用户在回路内，而不是回路外。

整体架构图

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

职责拆分：

会话编排器：处理用户输入、会话状态、重试和压缩策略。
Agent Core：只做“思考循环”和“状态推进”。
模型适配器：屏蔽不同模型供应商差异。
工具执行器：统一执行本地或远程工具。
观察与事件：把过程变成可见信号给 UI/日志系统。

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

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

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

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

消息协议（Message Protocol）

统一描述用户消息、助手消息、工具结果。

事件协议（Event Protocol）

统一描述开始、更新、结束、错误、工具执行状态。
目的：让 UI 和日志看到“过程”，不是只看到“结论”。

工具协议（Tool Contract）

工具名、参数结构（Schema，字段规则）、执行返回格式必须固定。

流式协议（Streaming Contract）

支持增量输出（delta，分段输出），保证用户实时反馈。

取消协议（Cancellation Contract）

任意环节都应响应中止信号，避免“停不下来”。

错误协议（Error Contract）

失败必须结构化（可机器处理），不能只靠字符串报错。

需要理解的基础设计模式

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

状态机（State Machine）

Agent 每一步都有状态转移（例如：等待输入 -> 生成输出 -> 工具执行 -> 回到生成）。

发布-订阅（Pub/Sub，发布与订阅）

Core 发事件，UI/日志订阅事件。
好处：核心逻辑不依赖具体界面。

适配器（Adapter）

把不同模型接口包装成统一调用方式。

策略模式（Strategy）

重试策略、工具并发策略、压缩策略可替换。

管道与过滤（Pipeline）

输入预处理 -> 模型调用 -> 工具执行 -> 后处理，是可插拔链路。

幂等与可恢复（Idempotency/Recoverability）

同一操作重复执行不应产生灾难性副作用，失败后能恢复。

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

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

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

设计理念

内核最小化

Core 只负责循环、状态、事件、工具编排。

外围可插拔

模型、工具、重试、上下文处理都可替换。

过程优先于结果

先保证过程可见、可控，再追求“聪明输出”。

会话优先于请求

把 Agent 当长期会话系统，不当单次 API 调用。

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{工程控制能力} $$

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

循环设计
协议设计
事件可观察性
可恢复与可扩展性

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

Agent 框架 on Steve Sun