Agent或Agentic Workflow

Agent 与 Agentic Workflow

简单判断标准：如果系统需要模型自主决定下一步调用什么工具、何时停止，那就是 Agent；如果步骤和分支主要由开发者预先定义，更接近 Agentic Workflow。

从 Function Calling 到 Tool Use 的演进

一年前主流做法是在 Prompt 里描述工具，让模型用自然语言「假装」调用 API；如今各厂商已把工具调用做成一等公民能力，但实现路径和工程要求发生了显著变化。

三代工具调用范式

关键能力变化

1. 从「尽力匹配」到「严格遵从」

OpenAI 在 2024 年 8 月推出 Structured Outputs（strict: true），通过约束解码保证输出 100% 符合 JSON Schema。在此之前，生产环境常需额外校验和重试逻辑。

2. 从单轮到并行、多轮 Agent 循环

早期 function calling 多为「一问一调」；现在默认支持并行 tool calls（一次响应发起多个工具调用），Agent 框架则在此基础上构建多轮 observe-think-act 循环：

用户输入 → 模型推理 → [tool_call_1, tool_call_2, ...]
         → 执行工具 → 将结果作为 tool_result 回传
         → 模型继续推理 → ... → 最终文本回复

3. 从厂商私有 API 到 MCP 开放标准

Anthropic 在 2024 年 11 月推出 Model Context Protocol (MCP)：工具以 Server 形式暴露，Client（Claude Desktop、Cursor、OpenCode 等）在运行时动态发现能力。原生 Tool Use 适合应用内强约束逻辑；MCP 适合跨应用、可复用的工具生态。生产系统往往两者结合。

各厂商 Tool Use 差异

旧式 vs 现代工具调用对比

# 旧式：Prompt 注入 + 文本解析（脆弱）
prompt = """
你有以下工具：search(query), calc(expr)
请用 JSON 格式回复：{"tool": "search", "args": {"query": "..."}}
"""
response = llm.generate(prompt)
tool_call = json.loads(extract_json(response))  # 经常解析失败

# 现代：原生 Tool Use API
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "查北京和上海天气"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"]
            }
        }
    }],
    tool_choice="auto"
)
# 模型可能一次返回多个 tool_calls，应用层并行执行后统一回传

现代编码 Agent 的核心逻辑

以 OpenCode、Claude Code、Cursor 为代表的编码 Agent，共享一套相似的架构模式，差异主要在权限模型、会话持久化和 IDE 集成方式。

典型架构分层

┌─────────────────────────────────────────┐
│  UI 层：TUI / IDE 插件 / Web / Desktop    │
├─────────────────────────────────────────┤
│  协议层：ACP（Agent Client Protocol）/ MCP │
├─────────────────────────────────────────┤
│  Agent 核心：推理循环 + 权限 + 会话状态    │
├─────────────────────────────────────────┤
│  工具层：读写文件 / Bash / LSP / 搜索 / MCP │
├─────────────────────────────────────────┤
│  模型层：多 Provider 路由（OpenAI/Anthropic/本地）│
└─────────────────────────────────────────┘

Agent 推理循环（以 OpenCode 为例）

OpenCode 等成熟编码 Agent 的核心不是「一个 Prompt」，而是事件驱动的 Agent 循环：

1. 接收任务：用户输入或子 Agent 委派
2. 构建上下文：system prompt + 项目记忆（AGENTS.md）+ 对话历史 + 工具列表
3. 模型推理：流式生成文本或 tool_use 块
4. 权限检查：根据 Agent 类型（Build / Plan）和 glob 规则决定 allow / deny / ask
5. 执行工具：懒加载注册表中的工具，实时通过事件总线更新 UI
6. 结果回传：tool_result 写入上下文，回到步骤 3
7. 终止判断：模型输出最终回复，或达到轮数/ token 上限

主 Agent 与子 Agent 分工

主 Agent 可通过 @mention 或框架内部路由调用子 Agent，形成分层任务分解，避免单次上下文塞入过多无关代码。

编码 Agent 的关键工程细节

• Edit 工具的多阶段匹配：LLM 输出的代码 patch 不精确时，用模糊匹配 + 分层 fallback 提高修改成功率
• Client/Server 分离：OpenCode 用持久化 Server + SQLite 保存会话，SSH 断线重连后任务不丢
• 项目记忆文件：AGENTS.md / CLAUDE.md 将项目约定注入每次会话，相当于「不训练模型的领域适配」
• MCP 扩展：连接外部 MCP Server（数据库、浏览器、自定义 API）无需改 Agent 核心代码

ReAct 与 Agentic 推理

ReAct（Reasoning + Acting）仍是理解 Agent 行为的基础框架：

• Thought：显式推理当前状态和下一步
• Action：选择并调用工具
• Observation：读取工具返回，更新状态

现代推理模型（o1、Qwen3 thinking、Claude extended thinking）将 Thought 内化到模型内部；框架层则负责把 Action/Observation 循环跑稳。详见 Agent实战 中的 ReAct 部分。

本章与其他章节的关系

下一节，我们进入 Agent 实战 章节，从 benchmark 到框架选型、持续演进与微调，系统掌握 Agent 开发与优化全流程。