从model到agent的进化之路

如何构建一个 Agent？从理解概念到实践路径

关键词：Build Agent

在当前 AI 技术语境中，“model” 通常指代的是大语言模型（LLM），这是我们讨论的基础共识。

而“agent”（代理）则是在模型基础上进一步演化的能力体。它不仅仅是响应式地回答问题，而是具备一定的自主性：
Agent 通常以接收人类用户的指令开始工作，或通过与用户进行交互式对话来明确任务目标。一旦目标清晰，agent 便能独立进行任务规划与执行，在过程中根据需要调用工具、获取环境反馈，并在遇到关键决策点或障碍时主动请求人类介入。

其典型工作流程如下：

用户输入 → 理解意图 → 规划任务 → 调用工具（如搜索、计算等）→ 生成响应 → 执行动作

理想的 agent 应具备两个核心特性：可靠（reliable）与可控（controllable），即既能稳定完成任务，又能在必要时被有效监督和干预。

---

Agent 的一种: Coding Agent

目前，我最感兴趣的方向是 Coding Agent —— 能够理解软件开发任务、自主修改代码文件、并通过测试验证结果的智能代理系统。

---

什么是 Agent？

根据 Anthropic 官方博客《Building Effective Agents》中的定义，“agent” 有多种理解方式：

• 一些团队将其视为完全自主的系统，可在长时间内利用多种工具完成复杂任务；
• 另一些则用于描述遵循预设流程的指令型系统。

Anthropic 将这些统称为“agentic systems”（类代理系统），并区分了两个关键架构类型：

• Workflows（工作流）：由代码预先定义调用路径，LLM 与工具按固定顺序协作；
• Agents（代理）：LLM 动态决定执行路径和工具使用，拥有对任务进程的控制权。

本文所讨论的 agent，更偏向后者——具备动态决策能力的自主系统。

---

开发建议：从 API 直接调用开始

Anthropic 建议开发者优先直接使用 LLM 的 API 构建系统，而不是一开始就依赖复杂的框架。许多高效的 agent 模式其实可以用几行代码实现。

虽然存在如 LangGraph等可视化或低代码工具，能快速搭建 agent 流程，但它们往往引入过多抽象层，导致底层提示难以调试，也容易诱发不必要的复杂设计。

✅ 推荐做法：先用原生 API 实现核心逻辑，理解底层机制后再考虑是否引入框架。

---

常见的构建模式：从 Workflows 到 Agents

以下是 Anthropic 总结的几种常见 agentic 系统模式，适合逐步演进至完整 agent 架构。

1. Workflow：Prompt Chaining（提示链）

将任务分解为多个顺序步骤，每个 LLM 调用处理前一步的输出。可在中间环节加入程序化检查（“gate”），确保流程正确。

适用场景：任务可清晰拆解为固定子任务，目标是通过降低单步难度提升整体准确性。

示例：

• 先生成营销文案，再翻译成多语言；
• 先写文档大纲，经规则校验后，再生成全文。

---

2. Workflow：Routing（路由分流）

根据输入内容分类，并引导至不同的下游处理流程、提示词或模型。

适用场景：面对多样化的请求类型，需差异化处理以避免性能妥协。

示例：

• 客服请求分为“咨询”、“退款”、“技术支持”，分别路由至专用流程；
• 简单问题交给轻量模型（如 Claude 3.5 Haiku），复杂问题交由强模型（如 Sonnet）处理，实现成本与效率平衡。

---

实践观察：AI 网关中的对话数据分析

在实际部署中，可通过 AI 网关查看完整的对话日志与调用链路，分析 agent 的行为路径与决策质量。

这类数据对于调试 agent 的规划能力、工具调用准确性和错误恢复机制至关重要。

---

总结

构建 agent 不等于追求最复杂的架构，而是选择最适合需求的系统设计。应始终遵循：

从简单出发，仅在必要时增加复杂性。

推荐路径：

1. 从优化单次 LLM 调用开始（结合检索、上下文示例）；
2. 尝试组合基础 workflow 模式（如 chaining、routing）；
3. 当任务无法预知步骤或需动态决策时，再引入真正的 agent 架构。

---

如需进一步深入，推荐阅读原文：https://www.anthropic.com/engineering/building-effective-agents

本文由AI润色