Agent开发系列（一）：框架篇

Agent开发系列 · 第 1/4 篇

框架篇 · 记忆篇 · 评测篇 · Skill篇

开发 Agent 时，很容易从一段 Prompt 开始，最后却得到一个难以调试、无法复用、也无法判断效果的系统。框架篇先不讨论具体 API，而是先把 Agent 应用的运行结构讲清楚。

一、从一次模型调用到 Agent Loop

普通 LLM 调用通常是“输入一个问题，得到一段回答”。Agent 则要在模型之外增加目标、状态、工具和执行循环。

一个典型的 Agent Loop 可以简化为：

1
2
3
4
5
6
观察当前状态
  -> 判断下一步行动
  -> 调用工具或生成结果
  -> 读取执行结果
  -> 更新状态
  -> 继续循环或终止

决定一个应用是不是 Agent，关键不在于是否使用了多个 Prompt，而在于它是否能根据中间结果改变后续行动。

二、Agent 系统的核心构件

构件 主要职责
Model 接收上下文、生成决策、调用工具
Message 承载角色、内容、工具结果和状态
Agent 定义决策策略、循环方式和终止条件
Tool 提供搜索、数据库、代码执行等外部能力
Workflow 控制串行、并行、条件和人工介入
Runtime 负责执行、并发、容错、日志和分布式部署

如果把这些部分都塞进一段 Prompt，系统在原型阶段可能运行得很快，但一旦需要排错、扩展或接入真实工具，维护成本就会迅速上升。

三、常见的 Agent 架构

1. 单 Agent + 工具

适合搜索、问答、代码修改等边界相对清晰的任务。系统有一个决策主体，外部能力通过 Tool 接入。

2. Router + 专家 Agent

先判断任务类型，再交给对应的专家 Agent。它适合任务类别明确、每个类别都有专门处理流程的场景。

3. Planner + Executor

Planner 负责拆解任务，Executor 负责执行步骤。关键问题是计划必须可验证，执行失败后还要能够重新规划。

4. Supervisor + 多 Agent

Supervisor 负责任务分配和结果汇总，多个 Agent 负责不同子任务。增加 Agent 数量并不自动提高效果，反而会增加消息成本、上下文同步和错误传播。

四、框架选型应该看什么

选择框架时，可以优先比较以下维度：

  1. 抽象程度：是否隐藏了必要的控制点。
  2. 可观测性：能否看到消息、工具调用、状态变化和错误。
  3. 编排能力：是否支持串行、并行、条件、循环和人工确认。
  4. 部署能力：是否支持异步、多进程和分布式运行。
  5. 生态兼容：是否方便接入模型、MCP、数据库和代码沙箱。

AgentScope 的价值在于提供了较完整的消息、Agent、Pipeline 和分布式运行时抽象。更具体的组件与使用方式可以继续阅读：AgentScope框架。

五、先判断是否需要 Agent

以下任务不一定需要 Agent：

  • 单轮文本生成
  • 固定的信息抽取
  • 流程完全确定的自动化任务
  • 只需要一次模型调用的分类或改写

这些场景使用普通 SDK 或确定性工作流通常更简单。只有当系统需要根据中间结果选择下一步行动时，Agent Loop 才真正有价值。

小结

框架篇的核心结论是：先设计运行结构，再选择框架。一个可靠的 Agent 系统至少应该具备清晰的模型边界、消息协议、工具接口、状态管理、终止条件和可观测性。

下一篇将进入记忆篇，讨论 Agent 如何在有限上下文里保存、检索和遗忘信息。