ai-agent-book 精选快照（<2MB 代码与文档，来自 github.com/bojieli/ai-agent-book）

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/context_engineering_part_1_8_zh.md

@@ -0,0 +1,653 @@
+用户现在需要翻译第五章的内容，也就是上下文工程的第一部分。我需要逐句准确翻译，注意专业术语和代码部分的处理。首先开头是“# Context Engineering [Part 1/8]”，翻译为“# 上下文工程 [第1部分/共8部分]”。然后逐段处理，比如“Context Engineering”翻译为“上下文工程”，代码部分要保留原样。现在开始逐句翻译：
+
+# 上下文工程 [第1部分/共8部分]
+## 上下文工程
+
+第1章将上下文定义为智能体在决策时刻的工作信息集。设计和管理该上下文——我们称之为**上下文工程**——是构建有效智能体的核心。在实践中，上下文包括智能体在给定交互中接收的所有信息：对话历史、系统指令、工具定义、检索文档、运行时状态和其他特定任务信息。从第1章介绍的框架视角看，上下文工程实现了框架的“上下文与工具”层的大部分内容：它决定智能体在每个决策点看到的信息以及这些信息的组织方式。良好的上下文设计为模型提供正确的背景、约束和行动接口，使其通用推理能力能有效应用于任务。
+
+![图2-1：上下文窗口组成概览](images/fig2-1.svg)
+
+## 上下文：智能体能力的上限
+大型语言模型在标准化基准测试中取得优异成果，但在真实业务场景中往往表现不佳。原因很简单：模型能力是通用的，而具体任务依赖于本地知识，如产品架构、业务规则、操作约束和内部约定。这些信息通常不存在于模型参数中。
+
+设想一位非常有能力的工程师加入新团队。他可能拥有深厚的理论知识和强大的编程能力，但尚不了解产品架构、业务逻辑、技术债务或团队规范。如果关键架构决策分散在个人记忆中且代码库文档匮乏，即使是杰出的工程师也难以快速创造价值。当今的人工智能智能体面临同样的问题。
+
+以编码智能体为例。面对相同指令“帮我修复这个漏洞”，智能体接收的上下文质量决定了它能否完成任务：
+- **代码上下文**：代码库结构、模块职责、核心数据结构和编码标准。缺乏此信息，智能体可能生成语法正确但与项目风格或架构不一致的代码。
+- **流程要求**：Git分支策略、提交规范、审查流程和CI/CD要求。缺乏此信息，智能体可能直接将未经测试的代码提交到主分支。
+- **环境配置**：开发设置、测试数据库连接字符串、阶段部署程序和API密钥管理实践。缺乏此信息，本地运行正常的修复可能在测试环境中立即失败。
+
+这三类——代码、流程和环境——构成智能体有效工作所需的最小上下文。模型固有的能力只是基础；上下文设定了智能体能力的上限。具有良好组织上下文的中等能力模型往往能胜过在上下文不足情况下运行的更强模型。
+
+因此，上下文工程是用当今模型构建有效智能体的核心。这不仅仅是向提示词中添加更多文本的问题。它需要系统地设计、组织并提供模型完成任务所需的背景知识。上下文工程是技术问题，但从根本上说是组织问题。在许多团队中，关键知识仍未明确：架构决策存在于高级工程师的记忆中，业务规则非正式传递，重要上下文埋藏在私人聊天日志中。如果团队自身是不良的信息环境，即使强大的人工智能智能体也会受限。
+
+在远程环境中有效工作的团队通常也为人工智能智能体提供了有效的环境。像Linux内核这样的开源项目就是有启发性的例子：分布在世界各地的开发者维护该项目已超过三十年。这之所以可行，是因为该项目具有透明的、文档驱动的沟通文化。讨论公开，决策记录在案，新人可通过阅读历史了解代码演进。同样的工作风格自然创造了对人工智能友好的环境：信息公开、可检索且结构化。
+
+每次智能体开始任务时，将其视为新的团队成员。有了足够的背景，它能产出高质量工作；缺乏背景，其大部分智能被浪费。因此，构建人工智能原生团队主要是文档工作，而非仅仅部署新工具。
+
+OpenAI研究员翁佳怡清晰地表达了这一点：**“对人类和模型而言，最重要的是上下文。”** 回顾自己的工作，他指出：“我在OpenAI的工作并不难。如果其他人拥有我所有的上下文，他们也能做到。” 同样的原则适用于智能体：智能体能力的上限不仅由模型大小决定，还由每个决策点提供的上下文的完整性和精确性决定。翁佳怡还观察到团队合作中的核心问题是上下文不一致，且人工智能短期内无法取代人类的一个原因是人工智能和人类不共享相同的环境。上下文工程正是解决这个问题：如何系统地向模型提供智能体所需的结构化背景信息。
+
+下一个问题是如何在技术层面将这些上下文信息提供给大语言模型。
+
+## 智能体如何调用大语言模型：API级上下文结构
+本节以OpenAI的Chat Completions API为例进行具体说明。Anthropic、谷歌等提供商在细节上有所不同，但它们面向智能体的API遵循类似模式：每次模型调用由结构化对话历史和一组可用工具定义构建。理解这种结构是本章后续讨论的上下文工程技术的基础。
+
+### 四种消息角色
+在Chat Completions风格的API中，核心输入是**消息列表**，通常命名为`messages`。每条消息有一个`role`字段，告诉模型如何解释消息及其来源：
+- **system**：开发者编写的指令，定义智能体的身份、行为、约束和工作流。模型将其视为高优先级指令。在大多数对话中，系统消息在消息列表开头出现一次。
+- **user**：最终用户的输入，代表智能体需要处理的请求。
+- **assistant**：之前的模型输出，包括自然语言回复和工具调用请求。在多轮交互中，这些消息包含在后续请求中，以便无状态的下一次模型调用能访问之前的轨迹。
+- **tool**：智能体框架执行工具后返回的结果。每个工具结果通过`tool_call_id`与相应的工具调用关联，使模型能将每个结果与其生成的请求关联起来。
+
+工具定义不是消息。它们在单独的`tools`字段中提供，声明模型可用的工具并指定每个工具接受的参数。
+
+### 单轮请求：最简单的API调用
+![图2-2：单轮API调用的请求与响应结构](images/fig2-2.svg)
+
+从最简单的情况开始：没有工具调用的单轮请求。用户问“你好，你是谁？”。示例使用本地部署的Qwen3-0.6B模型，与本节后面的本地大语言模型部署实验相连。示例中的时间戳仅用于演示，与本书时间线无关。
+
+```javascript
+// ═══ 智能体框架构造的请求 ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 开发者编写
+      "content": "You are a helpful coding assistant. Follow user instructions."
+    },
+    {
+      "role": "user",                              // ← 用户输入
+      "content": "Hello, who are you?"
+    }
+  ]
+}
+```
+
+```javascript
+// ═══ API返回的响应 ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": "Hi! I'm a coding assistant. I can help you write code, debug issues, and explain technical concepts. How can I help?"
+    }
+  }]
+}
+```
+
+此请求仅包含两条消息：一条包含开发者编写规则的系统消息和一条包含用户输入的用户消息。模型返回助手消息作为回复。这是最基本的大语言模型API交互模式：**每次调用无状态，因此请求的消息列表必须包含模型所需的所有信息**。
+
+### 带工具调用的多轮交互：智能体的核心循环
+真实的智能体工作流通常比单轮问答复杂。当用户问“温哥华当前的时间和天气是什么？”时，模型需要访问动态外部信息：当前时间和最新天气。以下示例逐步展示智能体框架与模型之间的每次交互。
+
+![图2-3：两次工具调用的完整交互序列](images/fig2-3.svg)
+
+**第一次API调用——智能体框架发送初始请求：**
+
+```javascript
+// ═══ 智能体框架构造的请求（第1次调用） ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 开发者编写
+      "content": "You are a helpful assistant. Use the provided tools to get real-time information when needed."
+    },
+    {
+      "role": "user",                              // ← 用户输入
+      "content": "What's the current time and weather in Vancouver?"
+    }
+  ],
+  "tools": [                                       // ← 开发者定义的工具
+    {
+      "type": "function",
+      "function": {
+        "name": "get_current_time",
+        "description": "Get the current date and time in a specific timezone",
+        "parameters": {
+          "type": "object",
+          "properties": {
+            "timezone": { "type": "string", "description": "Timezone name, e.g. America/Vancouver" }
+          }
+        }
+      }
+    },
+    {
+      "type": "function",
+      "function": {
+        "name": "get_weather",
+        "description": "Get the current weather for a specific city",
+        "parameters": {
+          "type": "object",
+          "properties": {
+            "city": { "type": "string", "description": "City name" },
+            "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
+          }
+        }
+      }
+    }
+  ]
+}
+```
+
+**模型返回工具调用请求（非最终回复）：**
+
+```javascript
+// ═══ API返回的响应（模型决定调用工具） ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": null,                             // 无文本响应
+      "tool_calls": [                              // 模型请求两次工具调用
+        {
+          "id": "call_abc123",
+          "type": "function",
+          "function": {
+            "name": "get_current_time",
+            "arguments": "{\"timezone\": \"America/Vancouver\"}"
+          }
+        },
+        {
+          "id": "call_def456",
+          "type": "function",
+          "function": {
+            "name": "get_weather",
+            "arguments": "{\"city\": \"Vancouver\", \"unit\": \"celsius\"}"
+          }
+        }
+      ]
+    }
+  }]
+}
+```
+
+模型尚未回答用户的问题。相反，它返回两个**工具调用请求**：一个用于当前时间，一个用于天气。由于这些请求是独立的，智能体框架可以并行执行它们。**模型发出调用请求；智能体框架执行实际调用。** 这种责任划分是智能体架构的核心：模型决定调用哪个工具及传递什么参数，而框架调用API、运行代码并返回结果。
+
+**智能体框架执行工具，然后发起第二次API调用：**
+
+在接收模型的工具调用请求后，智能体框架执行两个工具（例如，调用时间API和天气API），然后将**完整的对话历史连同工具执行结果**发送回模型：
+
+```javascript
+// ═══ 智能体框架构造的请求（第2次调用） ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 与第1次调用相同
+      "content": "You are a helpful assistant. Use the provided tools to get real-time information when needed."
+    },
+    {
+      "role": "user",                              // ← 与第1次调用相同
+      "content": "What's the current time and weather in Vancouver?"
+    },
+    {
+      "role": "assistant",                         // ← 第1次调用的模型输出，逐字包含
+      "content": null,
+      "tool_calls": [
+        { "id": "call_abc123", "function": { "name": "get_current_time", "arguments": "{\"timezone\": \"America/Vancouver\"}" } },
+        { "id": "call_def456", "function": { "name": "get_weather", "arguments": "{\"city\": \"Vancouver\", \"unit\": \"celsius\"}" } }
+      ]
+    },
+    {
+      "role": "tool",                              // ← 智能体框架生成（工具执行结果）
+      "tool_call_id": "call_abc123",
+      "content": "{\"timezone\": \"America/Vancouver\", \"datetime\": \"2025-09-13T05:18:47\", \"day_of_week\": \"Saturday\"}"
+    },
+    {
+      "role": "tool",                              // ← 智能体框架生成（工具执行结果）
+      "tool_call_id": "call_def456",
+      "content": "{\"city\": \"Vancouver\", \"temperature\": 13.2, \"unit\": \"celsius\", \"conditions\": \"clear\", \"humidity\": 93}"
+    }
+  ],
+  "tools": [ ... ]                                 // ← 与上述相同的工具定义，省略
+}
+```
+
+这里有三个关键细节：
+1. **第二次请求包含第一次请求的完整对话历史** — 系统消息、用户消息、包含工具调用的助手消息和新添加的工具结果。这说明了API的无状态性质：智能体框架必须在每个请求中包含相关历史。
+2. **第一次助手消息逐字插入消息列表** — 这使下一次模型调用能访问前一次调用中做出的工具调用决策。
+3. **工具消息通过`tool_call_id`与相应的工具调用关联** — 这告诉模型哪个结果属于哪个请求的调用。
+
+**模型根据工具结果生成最终响应：**
+
+```javascript
+// ═══ API返回的响应（最终回复） ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": "It's currently 5:18 AM on Saturday, September 13, 2025 in Vancouver.\n\nWeather: 13.2°C with clear skies and 93% humidity. It's quite cool this morning - you might want to grab a jacket."
+    }
+  }]
+}
+```
+
+这次，模型不返回`tool_calls`；它返回文本响应，因为工具结果提供了足够的信息来回答用户的问题。如果需要更多信息（例如，用户问“东京呢？”），模型可以再次返回`tool_calls`，智能体框架重复相同的循环：执行工具、发送结果、再次调用模型。**这个“请求→工具调用→执行→返回结果→下一次请求”循环是第1章介绍的ReAct循环的API级实现。**
+
+### 用代码实现智能体的核心循环
+现在JSON结构清晰，我们可以在Python中连接上述步骤。以下是围绕单个循环构建的最小智能体实现：
+
+```python
+from openai import OpenAI
+
+client = OpenAI()
+
+# ── 工具定义 ──
+tools = [
+    {
+        "type": "function",
+        "function": {
+            "name": "get_current_time",
+            "description": "Get the current date and time in a specific timezone",
+            "parameters": {
+                "type": "object",
+                "properties": {
+                    "timezone": {"type": "string", "description": "Timezone name, e.g. America/Vancouver"}
+                },
+            },
+        },
+    },
+    {
+        "type": "function",
+        "function": {
+            "name": "get_weather",
+            "description": "Get the current weather for a specific city",
+            "parameters": {
+                "type": "object",
+                "properties": {
+                    "city": {"type": "string", "description": "City name"},
+                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
+                },
+            },
+        },
+    },
+]
+
+# ── 工具执行函数（带固定结果的存根；实际实现必须解析JSON `arguments`并调用实际API） ──
+def execute_tool(name, arguments):
+    if name == "get_current_time":
+        return '{"datetime": "2025-09-13T05:18:47", "day_of_week": "Saturday"}'
+    elif name == "get_weather":
+        return '{"temperature": 13.2, "unit": "celsius", "conditions": "clear", "humidity": 93}'
+
+# ── 初始消息列表 ──
+messages = [
+    {"role": "system", "content": "You are a helpful assistant. Use tools to get real-time information when needed."},
+    {"role": "user", "content": "What's the current time and weather in Vancouver?"},
+]
+
+# ── 智能体核心循环 ──
+# 生产代码在此处需要max_iterations限制：如本章后面所述，智能体可能永远重复相同的工具调用
+while True:
+    response = client.chat.completions.create(
+        model="Qwen3-0.6B", messages=messages, tools=tools
+    )
+    assistant_message = response.choices[0].message
+
+    # 将模型的响应追加到消息列表（无论是文本还是工具调用）
+    messages.append(assistant_message)
+
+    # 如果没有请求工具调用，模型已生成最终响应
+    if not assistant_message.tool_calls:
+        print(assistant_message.content)
+        break
+
+    # 执行模型请求的每个工具，将结果追加到消息列表
+    for tool_call in assistant_message.tool_calls:
+        result = execute_tool(tool_call.function.name, tool_call.function.arguments)
+        messages.append({
+            "role": "tool",
+            "tool_call_id": tool_call.id,
+            "content": result,
+        })
+    # 返回循环顶部，使用更新后的消息列表再次调用模型
+```
+
+循环有一个主要分支：**如果模型返回`tool_calls`，执行工具并继续；否则，输出结果并退出。** 在此过程中，`messages`列表随着每一轮追加模型回复和任何工具执行结果而不断增长。
+
+`messages`列表在各轮中的变化如下：
+
+**初始状态（第一次调用前）：**
+```
+messages = [
+  { role: "system",  content: "You are a helpful assistant..." },     # 开发者编写
+  { role: "user",    content: "What's the current time and weather in Vancouver?" },  # 用户输入
+]
+```
+
+**第一次调用后（模型返回工具调用）：**
+```
+messages = [
+  { role: "system",    content: "..." },
+  { role: "user",      content: "What's the current time..." },
+  { role: "assistant", tool_calls: [get_current_time, get_weather] },  # + 模型生成
+  { role: "tool",      tool_call_id: "call_abc", content: "{time...}" },  # + 框架执行
+  { role: "tool",      tool_call_id: "call_def", content: "{weather...}" },  # + 框架执行
+]
+```</think># 上下文工程 [第1部分/共8部分]
+## 上下文工程
+
+第1章将上下文定义为智能体在决策时刻的工作信息集。设计和管理该上下文——我们称之为**上下文工程**——是构建有效智能体的核心。在实践中，上下文包括智能体在给定交互中接收的所有信息：对话历史、系统指令、工具定义、检索文档、运行时状态和其他特定任务信息。从第1章介绍的框架视角看，上下文工程实现了框架的“上下文与工具”层的大部分内容：它决定智能体在每个决策点看到的信息以及这些信息的组织方式。良好的上下文设计为模型提供正确的背景、约束和行动接口，使其通用推理能力能有效应用于任务。
+
+![图2-1：上下文窗口组成概览](images/fig2-1.svg)
+
+## 上下文：智能体能力的上限
+大型语言模型在标准化基准测试中取得优异成果，但在真实业务场景中往往表现不佳。原因很简单：模型能力是通用的，而具体任务依赖于本地知识，如产品架构、业务规则、操作约束和内部约定。这些信息通常不存在于模型参数中。
+
+设想一位非常有能力的工程师加入新团队。他可能拥有深厚的理论知识和强大的编程能力，但尚不了解产品架构、业务逻辑、技术债务或团队规范。如果关键架构决策分散在个人记忆中且代码库文档匮乏，即使是杰出的工程师也难以快速创造价值。当今的人工智能智能体面临同样的问题。
+
+以编码智能体为例。面对相同指令“帮我修复这个漏洞”，智能体接收的上下文质量决定了它能否完成任务：
+- **代码上下文**：代码库结构、模块职责、核心数据结构和编码标准。缺乏此信息，智能体可能生成语法正确但与项目风格或架构不一致的代码。
+- **流程要求**：Git分支策略、提交规范、审查流程和CI/CD要求。缺乏此信息，智能体可能直接将未经测试的代码提交到主分支。
+- **环境配置**：开发设置、测试数据库连接字符串、阶段部署程序和API密钥管理实践。缺乏此信息，本地运行正常的修复可能在测试环境中立即失败。
+
+这三类——代码、流程和环境——构成智能体有效工作所需的最小上下文。模型固有的能力只是基础；上下文设定了智能体能力的上限。具有良好组织上下文的中等能力模型往往能胜过在上下文不足情况下运行的更强模型。
+
+因此，上下文工程是用当今模型构建有效智能体的核心。这不仅仅是向提示词中添加更多文本的问题。它需要系统地设计、组织并提供模型完成任务所需的背景知识。上下文工程是技术问题，但从根本上说是组织问题。在许多团队中，关键知识仍未明确：架构决策存在于高级工程师的记忆中，业务规则非正式传递，重要上下文埋藏在私人聊天日志中。如果团队自身是不良的信息环境，即使强大的人工智能智能体也会受限。
+
+在远程环境中有效工作的团队通常也为人工智能智能体提供了有效的环境。像Linux内核这样的开源项目就是有启发性的例子：分布在世界各地的开发者维护该项目已超过三十年。这之所以可行，是因为该项目具有透明的、文档驱动的沟通文化。讨论公开，决策记录在案，新人可通过阅读历史了解代码演进。同样的工作风格自然创造了对人工智能友好的环境：信息公开、可检索且结构化。
+
+每次智能体开始任务时，将其视为新的团队成员。有了足够的背景，它能产出高质量工作；缺乏背景，其大部分智能被浪费。因此，构建人工智能原生团队主要是文档工作，而非仅仅部署新工具。
+
+OpenAI研究员翁佳怡清晰地表达了这一点：**“对人类和模型而言，最重要的是上下文。”** 回顾自己的工作，他指出：“我在OpenAI的工作并不难。如果其他人拥有我所有的上下文，他们也能做到。” 同样的原则适用于智能体：智能体能力的上限不仅由模型大小决定，还由每个决策点提供的上下文的完整性和精确性决定。翁佳怡还观察到团队合作中的核心问题是上下文不一致，且人工智能短期内无法取代人类的一个原因是人工智能和人类不共享相同的环境。上下文工程正是解决这个问题：如何系统地向模型提供智能体所需的结构化背景信息。
+
+下一个问题是如何在技术层面将这些上下文信息提供给大语言模型。
+
+## 智能体如何调用大语言模型：API级上下文结构
+本节以OpenAI的Chat Completions API为例进行具体说明。Anthropic、谷歌等提供商在细节上有所不同，但它们面向智能体的API遵循类似模式：每次模型调用由结构化对话历史和一组可用工具定义构建。理解这种结构是本章后续讨论的上下文工程技术的基础。
+
+### 四种消息角色
+在Chat Completions风格的API中，核心输入是**消息列表**，通常命名为`messages`。每条消息有一个`role`字段，告诉模型如何解释消息及其来源：
+- **system**：开发者编写的指令，定义智能体的身份、行为、约束和工作流。模型将其视为高优先级指令。在大多数对话中，系统消息在消息列表开头出现一次。
+- **user**：最终用户的输入，代表智能体需要处理的请求。
+- **assistant**：之前的模型输出，包括自然语言回复和工具调用请求。在多轮交互中，这些消息包含在后续请求中，以便无状态的下一次模型调用能访问之前的轨迹。
+- **tool**：智能体框架执行工具后返回的结果。每个工具结果通过`tool_call_id`与相应的工具调用关联，使模型能将每个结果与其生成的请求关联起来。
+
+工具定义不是消息。它们在单独的`tools`字段中提供，声明模型可用的工具并指定每个工具接受的参数。
+
+### 单轮请求：最简单的API调用
+![图2-2：单轮API调用的请求与响应结构](images/fig2-2.svg)
+
+从最简单的情况开始：没有工具调用的单轮请求。用户问“你好，你是谁？”。示例使用本地部署的Qwen3-0.6B模型，与本节后面的本地大语言模型部署实验相连。示例中的时间戳仅用于演示，与本书时间线无关。
+
+```javascript
+// ═══ 智能体框架构造的请求 ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 开发者编写
+      "content": "You are a helpful coding assistant. Follow user instructions."
+    },
+    {
+      "role": "user",                              // ← 用户输入
+      "content": "Hello, who are you?"
+    }
+  ]
+}
+```
+
+```javascript
+// ═══ API返回的响应 ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": "Hi! I'm a coding assistant. I can help you write code, debug issues, and explain technical concepts. How can I help?"
+    }
+  }]
+}
+```
+
+此请求仅包含两条消息：一条包含开发者编写规则的系统消息和一条包含用户输入的用户消息。模型返回助手消息作为回复。这是最基本的大语言模型API交互模式：**每次调用无状态，因此请求的消息列表必须包含模型所需的所有信息**。
+
+### 带工具调用的多轮交互：智能体的核心循环
+真实的智能体工作流通常比单轮问答复杂。当用户问“温哥华当前的时间和天气是什么？”时，模型需要访问动态外部信息：当前时间和最新天气。以下示例逐步展示智能体框架与模型之间的每次交互。
+
+![图2-3：两次工具调用的完整交互序列](images/fig2-3.svg)
+
+**第一次API调用——智能体框架发送初始请求：**
+
+```javascript
+// ═══ 智能体框架构造的请求（第1次调用） ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 开发者编写
+      "content": "You are a helpful assistant. Use the provided tools to get real-time information when needed."
+    },
+    {
+      "role": "user",                              // ← 用户输入
+      "content": "What's the current time and weather in Vancouver?"
+    }
+  ],
+  "tools": [                                       // ← 开发者定义的工具
+    {
+      "type": "function",
+      "function": {
+        "name": "get_current_time",
+        "description": "Get the current date and time in a specific timezone",
+        "parameters": {
+          "type": "object",
+          "properties": {
+            "timezone": { "type": "string", "description": "Timezone name, e.g. America/Vancouver" }
+          }
+        }
+      }
+    },
+    {
+      "type": "function",
+      "function": {
+        "name": "get_weather",
+        "description": "Get the current weather for a specific city",
+        "parameters": {
+          "type": "object",
+          "properties": {
+            "city": { "type": "string", "description": "City name" },
+            "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
+          }
+        }
+      }
+    }
+  ]
+}
+```
+
+**模型返回工具调用请求（非最终回复）：**
+
+```javascript
+// ═══ API返回的响应（模型决定调用工具） ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": null,                             // 无文本响应
+      "tool_calls": [                              // 模型请求两次工具调用
+        {
+          "id": "call_abc123",
+          "type": "function",
+          "function": {
+            "name": "get_current_time",
+            "arguments": "{\"timezone\": \"America/Vancouver\"}"
+          }
+        },
+        {
+          "id": "call_def456",
+          "type": "function",
+          "function": {
+            "name": "get_weather",
+            "arguments": "{\"city\": \"Vancouver\", \"unit\": \"celsius\"}"
+          }
+        }
+      ]
+    }
+  }]
+}
+```
+
+模型尚未回答用户的问题。相反，它返回两个**工具调用请求**：一个用于当前时间，一个用于天气。由于这些请求是独立的，智能体框架可以并行执行它们。**模型发出调用请求；智能体框架执行实际调用。** 这种责任划分是智能体架构的核心：模型决定调用哪个工具及传递什么参数，而框架调用API、运行代码并返回结果。
+
+**智能体框架执行工具，然后发起第二次API调用：**
+
+在接收模型的工具调用请求后，智能体框架执行两个工具（例如，调用时间API和天气API），然后将**完整的对话历史连同工具执行结果**发送回模型：
+
+```javascript
+// ═══ 智能体框架构造的请求（第2次调用） ═══
+{
+  "model": "Qwen3-0.6B",
+  "messages": [
+    {
+      "role": "system",                           // ← 与第1次调用相同
+      "content": "You are a helpful assistant. Use the provided tools to get real-time information when needed."
+    },
+    {
+      "role": "user",                              // ← 与第1次调用相同
+      "content": "What's the current time and weather in Vancouver?"
+    },
+    {
+      "role": "assistant",                         // ← 第1次调用的模型输出，逐字包含
+      "content": null,
+      "tool_calls": [
+        { "id": "call_abc123", "function": { "name": "get_current_time", "arguments": "{\"timezone\": \"America/Vancouver\"}" } },
+        { "id": "call_def456", "function": { "name": "get_weather", "arguments": "{\"city\": \"Vancouver\", \"unit\": \"celsius\"}" } }
+      ]
+    },
+    {
+      "role": "tool",                              // ← 智能体框架生成（工具执行结果）
+      "tool_call_id": "call_abc123",
+      "content": "{\"timezone\": \"America/Vancouver\", \"datetime\": \"2025-09-13T05:18:47\", \"day_of_week\": \"Saturday\"}"
+    },
+    {
+      "role": "tool",                              // ← 智能体框架生成（工具执行结果）
+      "tool_call_id": "call_def456",
+      "content": "{\"city\": \"Vancouver\", \"temperature\": 13.2, \"unit\": \"celsius\", \"conditions\": \"clear\", \"humidity\": 93}"
+    }
+  ],
+  "tools": [ ... ]                                 // ← 与上述相同的工具定义，省略
+}
+```
+
+这里有三个关键细节：
+1. **第二次请求包含第一次请求的完整对话历史** — 系统消息、用户消息、包含工具调用的助手消息和新添加的工具结果。这说明了API的无状态性质：智能体框架必须在每个请求中包含相关历史。
+2. **第一次助手消息逐字插入消息列表** — 这使下一次模型调用能访问前一次调用中做出的工具调用决策。
+3. **工具消息通过`tool_call_id`与相应的工具调用关联** — 这告诉模型哪个结果属于哪个请求的调用。
+
+**模型根据工具结果生成最终响应：**
+
+```javascript
+// ═══ API返回的响应（最终回复） ═══
+{
+  "choices": [{
+    "message": {
+      "role": "assistant",                         // ← 模型生成
+      "content": "It's currently 5:18 AM on Saturday, September 13, 2025 in Vancouver.\n\nWeather: 13.2°C with clear skies and 93% humidity. It's quite cool this morning - you might want to grab a jacket."
+    }
+  }]
+}
+```
+
+这次，模型不返回`tool_calls`；它返回文本响应，因为工具结果提供了足够的信息来回答用户的问题。如果需要更多信息（例如，用户问“东京呢？”），模型可以再次返回`tool_calls`，智能体框架重复相同的循环：执行工具、发送结果、再次调用模型。**这个“请求→工具调用→执行→返回结果→下一次请求”循环是第1章介绍的ReAct循环的API级实现。**
+
+### 用代码实现智能体的核心循环
+现在JSON结构清晰，我们可以在Python中连接上述步骤。以下是围绕单个循环构建的最小智能体实现：
+
+```python
+from openai import OpenAI
+
+client = OpenAI()
+
+# ── 工具定义 ──
+tools = [
+    {
+        "type": "function",
+        "function": {
+            "name": "get_current_time",
+            "description": "Get the current date and time in a specific timezone",
+            "parameters": {
+                "type": "object",
+                "properties": {
+                    "timezone": {"type": "string", "description": "Timezone name, e.g. America/Vancouver"}
+                },
+            },
+        },
+    },
+    {
+        "type": "function",
+        "function": {
+            "name": "get_weather",
+            "description": "Get the current weather for a specific city",
+            "parameters": {
+                "type": "object",
+                "properties": {
+                    "city": {"type": "string", "description": "City name"},
+                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
+                },
+            },
+        },
+    },
+]
+
+# ── 工具执行函数（带固定结果的存根；实际实现必须解析JSON `arguments`并调用实际API） ──
+def execute_tool(name, arguments):
+    if name == "get_current_time":
+        return '{"datetime": "2025-09-13T05:18:47", "day_of_week": "Saturday"}'
+    elif name == "get_weather":
+        return '{"temperature": 13.2, "unit": "celsius", "conditions": "clear", "humidity": 93}'
+
+# ── 初始消息列表 ──
+messages = [
+    {"role": "system", "content": "You are a helpful assistant. Use tools to get real-time information when needed."},
+    {"role": "user", "content": "What's the current time and weather in Vancouver?"},
+]
+
+# ── 智能体核心循环 ──
+# 生产代码在此处需要max_iterations限制：如本章后面所述，智能体可能永远重复相同的工具调用
+while True:
+    response = client.chat.completions.create(
+        model="Qwen3-0.6B", messages=messages, tools=tools
+    )
+    assistant_message = response.choices[0].message
+
+    # 将模型的响应追加到消息列表（无论是文本还是工具调用）
+    messages.append(assistant_message)
+
+    # 如果没有请求工具调用，模型已生成最终响应
+    if not assistant_message.tool_calls:
+        print(assistant_message.content)
+        break
+
+    # 执行模型请求的每个工具，将结果追加到消息列表
+    for tool_call in assistant_message.tool_calls:
+        result = execute_tool(tool_call.function.name, tool_call.function.arguments)
+        messages.append({
+            "role": "tool",
+            "tool_call_id": tool_call.id,
+            "content": result,
+        })
+    # 返回循环顶部，使用更新后的消息列表再次调用模型
+```
+
+循环有一个主要分支：**如果模型返回`tool_calls`，执行工具并继续；否则，输出结果并退出。** 在此过程中，`messages`列表随着每一轮追加模型回复和任何工具执行结果而不断增长。
+
+`messages`列表在各轮中的变化如下：
+
+**初始状态（第一次调用前）：**
+```
+messages = [
+  { role: "system",  content: "You are a helpful assistant..." },     # 开发者编写
+  { role: "user",    content: "What's the current time and weather in Vancouver?" },  # 用户输入
+]
+```
+
+**第一次调用后（模型返回工具调用）：**
+```
+messages = [
+  { role: "system",    content: "..." },
+  { role: "user",      content: "What's the current time..." },
+  { role: "assistant", tool_calls: [get_current_time, get_weather] },  # + 模型生成
+  { role: "tool",      tool_call_id: "call_abc", content: "{time...}" },  # + 框架执行
+  { role: "tool",      tool_call_id: "call_def", content: "{weather...}" },  # + 框架执行
+]
+```

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/getting_started_with_ai_agents_part_1_5_zh.md

@@ -0,0 +1,112 @@
+# 人工智能智能体入门 [第1部分/共5部分]
+## 人工智能智能体入门
+
+如果你使用过Cursor编写代码，并且看到它搜索你的代码库、编辑多个文件并重新运行测试直到通过，那么你已经使用过人工智能智能体了。如果你使用过Deep Research通过反复搜索和阅读来研究某个主题，让Manus控制浏览器完成在线任务，让豆包手机助手订票或发送消息，或者让Pine AI协商更低的电信账单，情况也是如此。
+
+这些产品形式多样，但它们有一个共同特征：它们不再是被动的“你问，它回答”的对话。它们会规划自己的执行步骤，调用每个任务所需的工具，并根据结果调整策略。人工智能智能体正在成为与计算机交互的新方式。
+
+本章从实际示例开始，逐步回溯到人工智能智能体的核心组件：读者将亲身体验现代智能体的功能，了解其背后的架构，并学习构建智能体系统的设计模式和最佳实践。
+
+> **阅读提示**：本章是整本书的概念图：对核心公式、操作循环、工程框架和智能体设计模式进行简洁概述。它建立了贯穿后续章节的共享词汇和参考点。第一次阅读时不要试图记住每个概念；着眼于大局。后面的每一章都会扩展这里介绍的一个方面，你可以在需要重新定位时返回本章。
+
+## 现代智能体=大语言模型+上下文+工具
+
+现代智能体系统的本质可以用一个简洁的公式概括：**智能体=大语言模型（LLM）+上下文+工具**。这个公式简单实用——只要对每个术语进行宽泛理解：
+
+- **大语言模型是智能体的推理引擎**：它不仅仅是一组模型参数；它是智能体的决策核心，负责理解意图、推理、规划和判断。大语言模型的能力来自预训练期间获取的世界知识和语言能力，以及通过后训练编码的决策策略（第7章将介绍监督微调、强化学习等技术）。
+- **上下文是智能体的工作信息集**：不仅仅是输入模型的文本，而是智能体在每个决策点可用的工作信息集——环境、用户记忆、领域知识、自身状态和任务进度。就像一个人做决策时需要评估情况、回忆相关经验并参考资料一样，智能体的上下文窗口包含了它在那一刻可以使用的信息。
+- **工具是智能体的行动接口**：不仅仅是少数可调用的API函数，而是智能体可以采取行动的全套方式——从预定义的工具调用到按需加载的技能，从生成代码即时创建新能力到将工作委托给子智能体，从与用户互动到响应外部事件。
+
+更直观地说：**智能体=推理引擎+工作上下文+行动接口**。模型进行推理和决策，上下文提供这些决策所依赖的工作信息集，工具提供决策影响外部世界的接口。
+
+这三个组件正好对应强化学习（RL）中的三个核心概念（见第7章）。下表是**可选阅读**——如果你没有强化学习背景，可以随意跳过；后面的内容不依赖它。它仅帮助熟悉强化学习的读者将相关知识映射到本书的术语中：
+
+| 直觉           | 智能体组件 | RL概念（可选） | 角色                                                         |
+|----------------|------------|----------------|--------------------------------------------------------------|
+| **推理引擎**   | LLM        | **策略**       | 决定“下一步做什么”的决策逻辑——根据当前信息，从所有可用选项中选择最合适的行动 |
+| **工作上下文** | 上下文     | **观测空间**   | 智能体可用的所有信息——它可以观察、读取、记住的内容，以及它可以访问的系统 |
+| **行动接口**   | 工具       | **行动空间**   | 智能体可以做的所有事情——可用的“手段”，从发送消息到执行代码到控制接口 |
+
+### 观测空间和行动空间：模型与世界的接口
+
+在经典教科书《计算机体系结构：量化研究方法》中，亨尼西和帕特森在第1章开篇提出“什么是计算机体系结构？”，并将**指令集架构**（ISA）确定为软件和硬件之间的接口[^ch1-agent-interface]。这种视角为我们理解智能体提供了有用的方式：**观测空间和行动空间共同构成大语言模型与其外部环境之间的接口**。观测空间将环境中的信息转化为模型可以处理的上下文；行动空间将模型决策转化为对外部世界的操作。观测空间之外的信息对模型来说实际上不存在。行动空间之外的操作仍然是模型只能用语言推荐的事情，即使它完全知道应该做什么。
+
+因此，**一旦底层模型保持不变，提高智能体性能的主要系统工程手段通常是重新定义或扩展其观测空间和行动空间**。用本书的术语来说，这意味着扩展上下文和工具。许多看似需要“更智能模型”的问题实际上是接口问题：将与任务相关的数据带入上下文，或将所需操作暴露为工具，之前无法解决的任务可能无需重新训练模型就能解决。
+
+**Manus：合并分离的空间**。在Manus出现之前，生产型智能体主要遵循三条不同路径：深度研究、编码和计算机使用。Manus是第一个在一个系统中广泛影响地将三者融合的生产型智能体。网络扩大了它的观测空间；文件系统和代码执行扩大了它的行动空间；屏幕感知以及点击和打字将图形界面带入两者。Manus不仅仅通过替换更强的模型成为通用智能体。它融合了三种智能体的观测空间和行动空间，使一个智能体跨越了之前的产品边界。
+
+**OpenClaw：将接口扩展到用户的数字生活**。OpenClaw再次将两个空间向外扩展。它通过用户已经使用的消息通道（WhatsApp、Telegram、Slack、Discord、iMessage等）接收任务并返回结果，因此几乎可以从任何地方接触到智能体。其本地优先的网关，加上授权的工具、插件和技能，可以连接谷歌云端硬盘和Notion等云应用以及本地文件系统。因此，分散在账户和设备上的文件可以在用户明确授权下进入一个智能体的观测空间，并由其工具进行操作。与最初以云沙盒为中心的Manus形式相比（文件通常必须上传或单独配置连接器），本地优先的OpenClaw跨越了更广泛的数据边界。Manus后来添加了自己的谷歌云端硬盘连接器和对本地文件的桌面访问——这进一步强化了这一点：产品演进通常正是通过扩展观测空间和行动空间实现的[^ch1-agent-products]。
+
+扩展并不意味着立即将所有可用令牌和工具倒入模型。不相关的上下文会增加噪声，而太多工具会增加选择成本和安全风险。有用的扩展必须是**按需、相关且受控的**：检索应将正确信息放入上下文，工具发现应仅暴露当前需要的行动，权限和结果验证应约束这些行动。后面的章节将发展这些技术。
+
+[^ch1-agent-interface]: 约翰·L·亨尼西和大卫·A·帕特森，《计算机体系结构：量化研究方法》，第6版，摩根·考夫曼出版社，2019年，第1章“什么是计算机体系结构？”。该书区分了指令集架构、计算机组织和硬件；指令集架构专门是软件和硬件之间的接口。见https://shop.elsevier.com/books/computer-architecture/hennessy/978-0-12-811905-1
+
+[^ch1-agent-products]: Manus的官方材料描述其原始沙盒为孤立的云虚拟机。在介绍其谷歌云端硬盘连接器时，Manus明确回忆了早期在云端硬盘、桌面和Manus之间手动下载和上传文件的分散工作流程。当它在2026年3月推出“My Computer”时，称重要工作本地存在而非在云端是云沙盒的基本限制。OpenClaw的官方README描述了运行在用户自己设备上的本地优先、始终在线的个人助手，并列出了二十多个消息通道；其工具和插件系统可以添加云集成和本地能力。见https://manus.im/blog/manus-sandbox，https://manus.im/blog/manus-google-drive-connector，https://manus.im/blog/manus-my-computer-desktop，https://github.com/openclaw/openclaw，以及https://docs.openclaw.ai/tools
+
+理解每个组件的作用以及它们如何协同工作是构建有效智能体系统的基础。我们将从三者中最具体的一个——工具（行动接口）开始，向内深入到大型语言模型和上下文。首先，以下是不同类型智能体在这三个维度上的比较：
+
+| 智能体产品       | 工作上下文               | 行动接口                     | 策略                                                         |
+|------------------|--------------------------|------------------------------|--------------------------------------------------------------|
+| **编码智能体（例如Cursor）** | 需求文档、代码库、终端环境 | 开放式（内部推理、代码搜索、文件读写、命令执行等） | 增量式开发：理解需求→搜索相关代码→编辑代码→测试验证→调试修复 |
+| **搜索智能体（例如Deep Research）** | 网络资源、学术数据库、本地文件 | 开放式（内部推理、搜索查询、网络阅读、摘要生成） | 迭代深化：根据现有信息调整搜索方向，逐步合成完整报告         |
+| **计算机控制智能体（例如浏览器使用）** | 计算机屏幕、浏览器页面、文件系统 | 开放式（内部推理、点击、打字、滚动、截图、代码执行等） | 视觉感知+操作：观察屏幕→识别目标元素→执行操作→验证结果     |
+| **手机助手智能体（例如豆包）** | 手机屏幕、已安装应用       | 开放式（内部推理、点击、滑动、打字、打开应用等） | 意图理解+应用控制：理解用户需求→定位目标应用→执行操作→确认完成 |
+| **个人任务智能体（例如Pine AI）** | 用户账户信息、历史账单、服务提供商知识库 | 开放式（内部推理、打电话、发送邮件、填写表格、与用户确认） | 多步骤任务执行：收集信息→制定协商策略→联系服务提供商→协商→报告结果 |
+
+这些系统具有三个共同特征：**开放式行动空间**——不是从固定的按钮集中选择，而是生成任意自然语言和代码；**内部推理**——行动前进行规划；**连续交互**——根据环境反馈调整策略。这些能力正是来自推理引擎、工作上下文和行动接口的相互作用——即大语言模型、上下文和工具。
+
+### 工具：智能体的行动接口
+
+工具是智能体与外部世界的桥梁。它们将智能体从被动观察者转变为可以搜索、写入文件、运行代码、调用API、发送消息或操作接口的主动系统。没有工具，智能体仅限于文本生成；有了工具，它可以对外部系统采取行动。
+
+为了系统地讨论工具，我们可以根据智能体与世界交互的方向将其分为五种类型。在这个阶段，简要概述每种类型的代表性场景足以建立整体图景；后面的章节将深入探讨每种类型。
+
+**感知工具**允许智能体访问信息：搜索引擎提供实时网络数据，文件系统读取本地文档，API和数据库连接外部服务和企业核心数据。
+
+**执行工具**允许智能体对外部系统采取行动：代码执行、文件操作、系统命令和外部API调用将决策转化为具体行动。
+
+**协作工具**允许智能体与其他智能体分工：将专门任务委托给子智能体，在关键决策点请求人类确认，或在多智能体系统中协调行动。
+
+**事件触发工具**以与前三种类别根本不同的方式被调用：智能体不调用它们；它们作为外部输入到达，触发智能体开始工作。新邮件到来、预定时间到达或另一个系统触发Webhook回调；事件激活智能体并启动推理和行动。智能体从不自己调用这些工具，但它们仍然是它与外部世界交互的通道，因此我们将它们计入广义的工具系统。
+
+**用户通信工具**是智能体与用户通信的通道。执行工具改变外部世界，而通信工具传递信息——通过短信、语音通话、电子邮件等传递智能体的进度或主动签到。
+
+第4章将涵盖这五种类型的完整分类法和设计原则。工具设计的质量直接决定智能体可以可靠完成的任务：接口定义模糊，模型会滥用它们；错误处理不佳，单个失败的工具可能让智能体陷入困境；权限范围过广，一个智能体错误可能无法挽回。随着MCP（模型上下文协议）标准的传播，集成工具变得像安装插件一样简单——生态系统正在迅速扩展，但设计原则不会过时。
+
+**工具调用**（也称为函数调用）是现代大语言模型智能体的核心能力：它让模型以结构化方式调用外部工具，将大语言模型从纯文本生成器转变为可以通过外部接口行动的智能系统。本书通篇使用“工具调用”这一术语。
+
+工具调用分为四个步骤：首先，上下文告诉模型哪些工具可用（名称、用途、参数）；然后模型自行决定是否调用工具、调用哪个工具以及使用什么参数；接下来，工具运行后，其结果附加到上下文中；最后，模型根据该结果决定下一步行动。这个循环是后续介绍的ReAct的基础。
+
+以天气查询为例，API级别四步过程的简化表示如下：
+
+```
+步骤1：声明工具                  步骤2：模型决定调用
+tools: [{                             assistant: {
+  name: "get_weather",                  tool_calls: [{
+    parameters: {                           function: "get_weather",
+      city: "string"                        arguments: {city: "Beijing"}
+    }                                      }]
+}]                                    }
+
+步骤3：结果附加到上下文          步骤4：模型根据结果响应
+tool: {                               assistant: {
+  tool_call_id: "call_1",               content: "Today in Beijing: 28°C, sunny."
+  content: '{"temp":28,"sky":"clear"}' }
+}                                     }
+```
+
+开发者只需定义工具并执行调用；模型自己决定是否调用、调用哪个工具以及传递什么参数。第2章将详细检查这个API结构。
+
+为智能体设计工具时，从任务所需的最窄能力开始，然后随着任务变得更复杂逐步扩展。如果任务只需要基本算术，一个参数明确的计算器就足够；当任务扩展到读取电子表格、清理缺失值、计算统计数据和绘制图表时，一个受限的Python代码解释器比不断增长的专门工具集合更容易组合和探索。但通用性也增加了错误风险并扩大了攻击面：代码必须在隔离沙盒中运行，默认禁用网络访问，无法访问授权工作目录外的文件，并且对执行时间、CPU、内存和输出大小有限制。
+
+同样，单个日志工具适合记录一次执行；对于耗时数小时甚至数天的长时间运行任务，受控的虚拟工作目录可以保存计划、中间结果、执行日志和最终工件，以便智能体在多次运行中恢复。该目录还应限制可读和可写路径、存储容量和文件类型，并防止路径遍历，而不是将整个主机文件系统暴露给智能体。
+
+通用工具并不总是比专门工具更好。高风险操作或受严格业务约束的操作——如支付、数据删除、发送电子邮件和生产部署——仍应作为具有明确参数、受限权限和端到端可审计性的专用工具暴露，必要时添加预览和人类确认。因此，工具设计的核心原则是：**使用通用基础能力进行组合和探索；使用专门工具约束高风险操作并强制执行严格业务规则**。
+
+### 大语言模型：智能体的推理引擎
+
+大语言模型（LLM）是智能体的决策核心。给定用户请求，它首先必须推断真实意图（用户所说的往往不是他们真正想要的），然后将模糊或复杂的任务分解为可执行步骤。在整个执行过程中，它不断做出决策：下一步做什么、是否调用工具、调用哪个工具以及使用什么参数。这种理解–规划–执行能力来自预训练期间积累的知识，是工作流和自主智能体都依赖的基础。
+
+大语言模型智能体的一个显著能力是**内部推理**——在行动前，智能体可以规划和推理任务。这不会改变外部环境，但会显著改善后续行动。这种能力来自预训练（在大量互联网文本上的初始训练，通过它模型学习语言模式和世界知识）：模型利用编码在人类知识中的推理模式，包括数学定律、因果关系和分解问题的策略。因此，智能体的推理不是盲目试错；它建立在结构化知识体系之上。
+
+这种结构化推理让大语言模型智能体可以处理全新的任务而无需先前示例——零-shot和few-shot两个概念说明了这一点。直接表现是**零-shot泛化**：面对从未见过的任务，智能体通过重组已有的知识来处理它，无需示例。模型可能从未被明确教过写关于量子物理的诗，但它可以根据现有语言和物理知识生成合理的诗。

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/getting_started_with_ai_agents_part_2_5_zh.md

@@ -0,0 +1,115 @@
+# 人工智能智能体入门 [第2部分/共5部分]
+
+通过几个示例，大语言模型智能体还可以执行**少样本适配**：提示词中的两三个演示就足以让它学习新的任务模式。如果展示几个“用户评论->情感标签”的示例，它就能对新评论进行情感分类。简而言之：零样本意味着用没有示例的情况解决任务；少样本意味着从少量示例中学习模式。
+
+### 模型即智能体：当模型本身成为产品
+
+“模型即智能体”范式是人工智能智能体开发的最新方向。先进模型通过后训练（尤其是强化学习）将工具调用内化为原生能力：何时调用工具、调用哪个工具、使用什么参数——模型自行决定，无需手动编排。这并不意味着框架层不重要。相反：模型越强，周围的框架就越重要。在智能体语境中，框架是将模型能力转化为可靠任务执行的工程基础设施。它包括上下文管理、工具接口、安全约束以及验证和纠正机制（见本章最后一节）。
+
+模型拥有的决策权限越大，错误决策的影响就越大——这需要更精细的约束、验证和纠正来保持其可靠性。模型提供商的真正优势不是“让框架更薄”，而是能够共同优化模型及其周围的框架，持续迭代。
+
+但随之而来的是一个更深入的问题：如果模型不断变强，今天的框架最终会被模型吸收吗？在《苦涩的教训》中，里奇·萨顿回顾了人工智能研究七十年中反复出现的模式[^ch1-1]：研究人员反复将对领域的理解编码到系统中，实现短期收益，但最终输给了随计算和数据扩展的通用方法——搜索和学习。从这个角度看，框架中的多少约束、验证和纠正属于“人类先验”，是模型注定要内化的？本书的立场可以用八个汉字总结：**方向认同，节奏务实**。从方向上看，我们不怀疑模型会继续吸收框架的部分内容——工具调用和长视野规划曾经依赖外部编排，但现在是模型的原生能力。然而在实践中，这种吸收比直觉慢得多：训练以月为时间尺度进行，没有模型能在一次训练中内化所有真实业务的约束和偏好。模型当前的能力边界正是框架创造价值的地方。因此，框架工程不是对《苦涩的教训》的抵抗，而是在工程时间尺度上的实践：模型还不能可靠完成的事情，框架先覆盖；每当模型内化另一层，框架就舍弃该层，转向支持下一个能力前沿。这条主线贯穿全书——第2章从上下文工程角度提供务实答案，第8章进一步讨论智能体如何从操作经验中选择和验证下一次系统更新，后记回到模型是否会吸收框架的完整答案。
+
+[^ch1-1]: Sutton, Rich. “The Bitter Lesson”, 2019. http://www.incompleteideas.net/IncIdeas/BitterLesson.html
+
+### 智能体学习机制：从上下文适配到持续更新
+
+前面的讨论指出，模型可以通过强化学习将工具使用策略内化为原生能力。但智能体行为的变化不仅发生在训练期间。根据更新发生的位置和持续时间，这些变化可以理解为三个互补路径（图1-1）：任务内的上下文适配、跨任务的外部工件更新，以及训练周期内的参数更新。
+
+![图1-1：智能体能力更新的三个层次](images/fig1-1.svg)
+
+**上下文适配**发生在当前任务内。一旦示例、状态和检索结果进入上下文，模型可以立即调整行为，但这不会改变下一会话的持久状态。其优点是速度快、成本低；局限性源于上下文窗口和信息组织方式。第2章将详细解释这种适配形式的工作原理。
+
+为了让变化在任务间持续，系统可以更新**外部工件**：事实和经验可以组织成知识文档，可用语言表达的策略可以写入提示词或技能，确定性程序和约束可以编码到程序和框架中。这些工件可审计且可修订，但智能体仍必须在执行时通过上下文或工具接口访问它们。第3章到第5章建立知识和程序的基础，第8章讨论如何从评估的操作轨迹中生成此类更新。
+
+当目标是高维能力——如医学图像理解、自然语言风格或隐式决策策略——外部规则无法完全表达时，必须通过后训练更新**模型参数**。参数更新带来更高的部署成本，但可以产生自然且广泛的泛化；第7章系统介绍其方法。因此，这三个路径不是互斥的类别，而是在不同时间尺度上运作的协调机制：上下文支持即时适配，外部工件支持受控积累，参数内化难以明确表达的能力。
+
+### 上下文：智能体的工作集
+
+上下文是智能体在每个决策点可用的工作信息集。就像一个人做决策时需要桌上有正确的材料——任务说明、参考手册、之前的通信、最新数据——智能体的上下文窗口是它可以使用的信息。从API的角度（第2章详细介绍），每次大语言模型调用的上下文由五部分组成：
+
+- **系统提示词**：与用户在对话中输入的提示词不同，系统提示词由开发者编写，在整个对话中保持固定。它是智能体的“工作描述”——定义其身份、权限和行为规则。精心设计系统提示词是塑造智能体操作行为的方式。系统提示词还包含跨会话持久的**用户记忆**（偏好、过去行为、背景设置等个性化信息；见第3章），以及动态注入的环境状态。
+- **工具定义**：声明智能体可用工具的名称、功能描述和参数格式。没有工具定义，智能体无法识别或调用任何工具——消融研究（实验1-1）将验证这一点。工具定义与系统提示词一起构成整个对话中保持不变的**静态前缀**。（这是基础模式；自2026年起，生产框架还可以在上下文末尾按需加载完整工具架构而不破坏前缀——见第2章和第4章的工具定义部分。）
+- **用户消息**：用户的输入。用户消息还可能包含通过RAG（检索增强生成，详情见第3章）动态检索的**外部知识**——涵盖训练数据截止日期之外的信息或私有领域知识。
+- **助手消息**：模型之前生成的响应，可能包含三部分——`推理`（内部思维链，保持连贯性和决策可解释性）、`内容`（对用户的响应）和`工具调用`（智能体采取行动的方式）。在特定响应中，这三部分可能不会同时出现：例如，当智能体决定调用工具时，通常只有`推理`+`工具调用`；当给出最终答案时，通常只有`推理`+`内容`。
+- **工具结果**：智能体框架执行工具后返回的输出。这些结果是智能体下一步推理步骤的直接基础——让它从结果中学习而不是重复错误。
+
+前两项（系统提示词+工具定义）构成静态前缀；后三项（用户消息+助手消息+工具结果）构成随每次交互增长的动态消息历史。这五部分共同构成每次大语言模型推理的上下文。
+
+每个组件真的不可或缺吗？最直接的方法是**消融研究**——一次排除一个原因的诊断方法：移除组件A，看系统是否仍能工作，然后移除组件B，依此类推，直到每个组件的贡献清晰。实验1-1正是对上述五个组件应用这种方法。结果直接：没有工具定义，智能体完全无法行动；没有工具结果，它无法接收上一步的反馈，因此反复调用同一工具，陷入无限循环；没有助手消息中的推理，连续决策开始相互矛盾；没有消息历史，智能体失去任务连续性，从头重新开始任务，重复已做的步骤。每个组件的角色基于实验证据，而非理论推断。
+
+### 实验1-1 ★★：上下文的关键作用
+
+我们通过系统的**消融研究**探究每个上下文组件如何塑造智能体行为。上述五个组件中，四个被测试——系统提示词作为智能体的基本身份定义，豁免：没有它智能体完全没有角色意识，测试无意义。如图1-2所示，实验运行五组对照：保留所有组件的完整基线，加上四组各缺失一个的组，观察每个组件对智能体性能的影响。
+
+![图1-2：实验1-1——上下文消融研究设计](images/fig1-2.svg)
+
+实验结果揭示了每个上下文组件不可替代的作用。**工具定义**（静态前缀的一部分）是智能体行动能力的基础；没有它们，智能体无法识别或调用任何工具。**工具结果**是闭环控制的关键；缺失它们使智能体失去执行反馈，陷入无限循环。**推理过程**（助手消息中的推理部分）保留智能体先前决策的理由，使整体推理更连贯，防止矛盾决策。**消息历史**（用户消息、助手消息和前几轮的工具结果）防止冗余操作，保持任务执行连贯性，避免重复错误。
+
+实验的核心洞察：**上下文决定智能体在决策时拥有的信息，智能体只能基于该信息进行决策**。就像一个人缺少关键文件无法做出明智判断，智能体缺少任何上下文组件都会严重丧失决策能力——没有工具定义它不知道存在哪些工具；没有先前执行结果它不知道已做过什么。
+
+### ReAct循环
+
+有了三个组件，自然的问题是：它们如何协同工作？ReAct循环是将大语言模型、上下文和工具连接成一个系统的核心机制。我们可以逐步审视。
+
+智能体执行任务的核心模式称为**ReAct**（推理+行动）。名称只提到推理和行动，但实际循环有三个阶段：模型首先**推理**下一步做什么，然后调用工具**行动**，然后**观察**工具的结果并推理后续步骤。这个“推理→行动→观察→推理→行动→观察”循环重复直到任务完成。
+
+以聚合多种货币的收入为例，理解智能体的**轨迹**：智能体工作时积累的消息历史，包括用户消息、助手消息（其推理和工具调用）和工具结果。每次大语言模型调用，模型接收的完整上下文是**静态前缀**（系统提示词+工具定义）加上**轨迹**（动态消息历史）（图1-3）。这显示一个关键事实：**智能体上下文=静态前缀+轨迹**。具体来说，静态前缀是上述五个组件中的前两个（系统提示词+工具定义）；轨迹是后三个（用户消息+助手消息+工具结果，随每次交互增长）。模型从这个完整上下文生成下一步响应，然后附加到轨迹供后续调用。
+
+![图1-3：智能体轨迹——多货币聚合任务的ReAct循环](images/fig1-3.svg)
+
+以下是轨迹的伪代码结构：
+
+```
+trajectory = [
+  {role: "user", content: "Based on the company's quarterly revenue: Q1 2.5M USD, Q2 2.1M EUR, Q3 1.8M GBP, Q4 380M JPY, calculate the company's total annual revenue and average quarterly revenue"},
+  
+  # 第一次迭代 - LLM接收上述轨迹并生成响应
+  {role: "assistant",
+   reasoning: "Need to convert all currencies to USD...",
+   content: "",  # 无直接回复用户
+   tool_calls: [
+     {name: "convert_currency", args: {amount: 2100000, from: "EUR", to: "USD"}},
+     {name: "convert_currency", args: {amount: 1800000, from: "GBP", to: "USD"}},
+     {name: "convert_currency", args: {amount: 380000000, from: "JPY", to: "USD"}}
+   ]},
+  
+  # 智能体框架执行工具，将结果添加到轨迹
+  {role: "tool", content: "EUR->USD: 2282608.7"},
+  {role: "tool", content: "GBP->USD: 2278481.01"},
+  {role: "tool", content: "JPY->USD: 2541806.02"},
+  
+  # 第二次迭代 - LLM接收包含工具结果的完整轨迹
+  {role: "assistant",
+   reasoning: "Conversion results obtained, now need to aggregate and calculate...",
+   content: "",
+   tool_calls: [
+     {name: "code_interpreter", args: {code: "total = 2500000 + 2282608.7 + ..."}}
+   ]},
+  
+  {role: "tool", content: "Total: $9,602,895.73, Average: $2,400,723.93..."},
+  
+  # 第三次迭代 - LLM接收完整轨迹并生成最终答案
+  {role: "assistant",
+   reasoning: "All calculations complete, summarizing results...",
+   content: "FINAL ANSWER: Total revenue $9,602,895.73..."},
+]
+```
+
+注意系统提示词和工具定义未显示在轨迹中——它们作为静态前缀，在每次大语言模型调用前自动添加到轨迹前。
+
+在我们的实验中，这个循环清晰可见。第一轮，智能体分析任务并并行调用三个货币转换工具；第二轮，将转换结果输入代码解释器进行计算量更大的计算；第三轮，确认所有计算完成后，生成最终答案。一个复杂的多步骤任务在3次迭代和4次工具调用中完成。
+
+这种设计的优雅之处在于上下文的**累积性**。每次大语言模型调用都接收完整轨迹，因此模型知道任务处于哪个阶段、之前做了什么、结果如何。就像人们解决问题时不断回顾总结，智能体通过轨迹保持对任务的全局视图。而且因为轨迹结构化——用户消息、助手消息（推理+工具调用）和工具结果清晰分离——系统高度可解释和调试。
+
+轨迹不仅是执行记录，更是智能体能力的证据。大规模分析轨迹揭示行为模式、更好的决策路径和更好的工具设计。轨迹数据甚至可以提炼成知识库，或通过强化学习训练更强的智能体模型——闭合从经验学习的循环。
+
+现在我们理解了智能体的操作循环，我们检查两个实验，看看不同模型如何驱动它。
+
+### 实验1-2 ★：Kimi K3原生智能体能力
+
+这个实验展示了**Kimi K3**的原生智能体能力，这是“模型即智能体”范式的示例。由月之暗面科技在2026年发布的Kimi K3是具有约2.8万亿参数的专家混合模型（MoE）。MoE可视为专家团队：对于每种问题，系统仅激活最适合的少数专家而不是整个模型，在保持能力的同时不支付全部效率成本。Kimi K3有100万个令牌的上下文窗口、原生视觉理解和始终在线的“思考模式”。通过强化学习，它将工具调用的**决策策略**内化为原生能力：何时调用工具、调用哪个工具、使用什么参数都由模型决定，允许它自主执行网络搜索等任务。准确地说，内化的是*何时和如何调用*的决策；工具本身，如`web_search`和`code_runner`，仍作为API级内置工具在服务器端执行。Kimi通过名为Formula的服务器端脚本引擎运行这些官方工具。
+
+这里有三个观察重要。第一，强化学习训练让模型学习何时和如何使用工具，因此客户端不再需要手动编写工具调用的编排逻辑。第二，模型决定何时搜索和搜索什么，显示真正的自主性。第三，它根据搜索结果调整策略并判断是否有足够信息。值得澄清一个常见误解：**强化学习赋予模型决策策略**，而非工具本身。它教会何时调用工具、选择哪个工具、传递什么参数、接收结果后是否继续、如何将数十或数百次调用链成连贯推理；这些*是否和如何使用*的判断被写入模型权重。**工具及其执行由智能体框架或API内置提供**：`web_search`和`code_runner`的实现、代码沙盒、发出调用和返回结果的基础设施都在模型之外。强化学习优化决策策略；它没有将搜索引擎或代码沙盒嵌入模型权重中。因此，编排循环没有消失；它从客户端转移到服务器，而决策制定进入模型[^ch1-2]。
+
+[^ch1-2]: 感谢读者asdlem通过GitHub Issue #30指出并澄清，RL内化的是工具调用决策策略，而非工具执行机制。见https://github.com/bojieli/ai-agent-book/issues/30

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/getting_started_with_ai_agents_part_3_5_zh.md

@@ -0,0 +1,195 @@
+用户现在需要翻译第三章的内容，我需要逐句准确翻译。首先开头是“# Getting Started with AI Agents [Part 3/5]”，翻译为“# 人工智能智能体入门 [第3部分/共5部分]”。然后逐段处理，注意专业术语的准确，比如“Kimi K3’s notable advantage”翻译为“Kimi K3在智能体任务中的显著优势是……”，还有“Freeform Tool Calling”翻译为“自由格式工具调用”等。要确保语句通顺，符合中文技术文档的表达习惯。现在开始逐句翻译：
+
+# 人工智能智能体入门 [第3部分/共5部分]
+
+Kimi K3在智能体任务中的显著优势是**长链工具调用的稳定性**——它可以在整个过程中持续进行200-300次连续的工具调用，且推理连贯，远远超过大多数模型开始退化时的几十次调用。K3针对长视野编程和智能体工作负载进行了优化，发布了两种变体：K3 Max（用于对话和智能体任务）和K3 Swarm Max（用于大规模并行处理）。作为开源模型，它在软件工程和智能体基准测试中与顶级闭源系统相当——这证明强化学习可以赋予模型原生的智能体能力。
+
+#### 实验1-3 ★：GPT-5.6原生深度研究能力
+
+第二个实验使用**OpenAI GPT-5.6**展示了一个由API级内置工具支持的先进模型如何在服务器端闭合“搜索—阅读—分析”的编排循环，用于深度研究。GPT-5.6有三种变体——Sol（旗舰前沿模型）、Terra（日常工作的平衡模型）和Luna（快速、经济的轻量模型）——所有变体都将工具调用决策原生地留给模型，因此客户端不需要自己的编排框架。一个方便的功能是**自由格式工具调用**。传统上，模型调用工具必须将每个参数序列化为严格的JSON（结构化数据格式），非常像用严格格式规则填写表格。自由格式工具调用（通过API中类型为“custom”的工具声明）允许模型直接向工具发送原始文本（一段Python代码、一个SQL查询），完全避免JSON转义。值得强调的是，这是API参数格式的演进，而非模型架构的创新——客户端的工具调用循环（检测`tool_calls`→执行→返回结果）保持不变；仅参数从JSON字符串变为原始文本。GPT-5.6还引入了详细程度参数（控制输出细节）和推理努力参数（调整推理深度；Sol添加了最彻底推理时间的最大级别），让开发者根据任务复杂度调整模型行为。
+
+GPT-5.6与Responses API的**网络搜索和代码解释器**内置工具配合，提供了深度研究的核心机制：模型可以自主搜索网络获取实时信息并编写代码进行深入分析，实现“搜索→阅读→分析→再次搜索”的迭代研究过程。例如，面对“东盟10国首都之间的最短距离是多少？”这样的问题，GPT-5.6会自动搜索每个首都的地理坐标，然后编写Python代码计算所有首都对之间的大圆距离，最终确定最近的一对。类似地，在“搜索比特币过去一个月的趋势并进行技术分析”这样的任务中，它可以从多个金融数据源获取实时价格数据，使用专业技术分析库计算移动平均线、相对强弱指数（RSI）、MACD等技术指标，生成可视化图表并提供交易建议。
+
+更重要的是，GPT-5.6在模型层面内化了**OpenAI深度研究**产品的设计理念，引入了**意图澄清过程**。给定一个研究请求，GPT-5.6不会立即开始执行；它首先通过一系列问题澄清用户的真实意图。对于“搜索比特币过去一个月的趋势并进行技术分析”，它会首先询问：“您偏好哪个数据源？您希望分析哪些技术指标？”这种交互式澄清让GPT-5.6生成的研究报告更精确，更符合用户实际需求。
+
+GPT-5.6是“模型即智能体”的成熟示例——网络搜索、代码解释器和Responses API的其他内置工具在服务器端闭环执行；编排循环从客户端转移到API服务器，简化了客户端实现。模型仍然发出标准的工具调用；客户端只是不再需要自己构建“搜索—阅读—分析”的编排框架。其最值得注意的方面是意图澄清机制：模型不是立即执行任务，而是首先确认用户真正需要什么，然后制定研究策略。在执行开始前解决了“用户所说的”和“用户实际想要的”之间的差距。
+
+图1-4展示了“模型即智能体”范式下原生工具调用的完整架构，以及Kimi K3和GPT-5.6在实际任务中的ReAct执行过程。
+
+![图1-4：“模型即智能体”架构——原生工具调用](images/fig1-4.svg)
+
+## 框架工程：超越模型的竞争力
+
+到目前为止，你已经了解了智能体的核心工作原理：大语言模型在上下文的引导下运行ReAct循环，使用工具完成任务。上述实验表明基本机制有效——但也暴露了其脆弱性。模型可能会幻觉（发明不存在的工具或参数）、选择错误的工具或无法从错误中恢复。从工作演示到可靠产品存在巨大差距，而这些脆弱性正是框架工程需要解决的。本章前半部分回答了智能体是什么；后半部分回答了智能体如何在生产中可靠运行。
+
+前面的章节建立了核心公式：**智能体=大语言模型+上下文+工具**。它描述了智能体的**内部组成**：推理引擎、工作上下文和行动接口。框架工程为同一系统添加了第二个**实现层面**的视图：将大语言模型视为一个核心组件（模型），将围绕它构建的所有支持代码称为框架。这两个视图不是竞争关系；它们在不同抽象层次描述同一系统。我们切换到更通用的“模型”一词，因为框架工程的原则适用于任何能够推理和调用工具的模型，而非特定种类。框架的核心是原始公式中的“上下文+工具”，加上三层保障：**约束**（智能体可以做和不可以做的事情）、**验证**（是否正确完成了事情）和**纠正**（出错时如何恢复）。
+
+展开为等式，完整的生产级组成是：
+
+> **智能体=大语言模型+[上下文+工具+约束+验证+纠正]=模型+框架**
+
+一个最小化的工作智能体仅靠大语言模型、上下文和工具运行。要在长时间运行的生产工作负载中可靠运行，它还需要三层外部工程层——约束以防止越界，验证以捕获错误，纠正以从失败中恢复。这些层不是事后添加的独立模块；它们是围绕“上下文+工具”的保障。换句话说：最小公式是演示视图，扩展公式是生产视图——后者完全包含前者并在其周围添加安全网。
+
+一个例子阐明边界：将退款政策嵌入上下文中属于**上下文**，而检查退款金额不超过订单总额属于**约束**。执行API调用属于**工具**，而API超时后自动重试属于**纠正**。模型提供底层理解和推理；框架引导、约束并放大这些能力，使其可靠完成任务。在模型之外设计和优化此基础设施的工程实践是**框架工程**。
+
+一个具体例子展示框架的价值。假设你要求智能体退还用户3天前下的订单。**没有框架**：模型没有收到退款政策（没有上下文），不知道调用哪个API（没有工具），为用户伪造退款结果（没有验证），用户发现退款从未发生（没有纠正）。**有框架**：系统提示词指定7天退款政策（上下文），智能体调用`query_order`和`process_refund`工具执行操作（工具），框架检查退款不超过订单总额（约束），与数据库确认退款已完成（验证），API调用超时后自动重试（纠正）。同一个模型，结果大不相同。
+
+简而言之，没有框架的模型可能能力很强，但缺乏可靠完成任务所需的周围控制。
+
+更精确地说，模型之外的所有基础设施都属于框架。框架的核心是上下文和工具，围绕它们构建三种工程保障：
+
+| 功能     | 一句话职责                     | 与上下文/工具的关系 |
+|----------|--------------------------------|---------------------|
+| **上下文** | 为模型提供相关信息             | 核心能力            |
+| **工具**   | 为模型提供行动接口             | 核心能力            |
+| **约束**   | 设置行为边界——可以做和不可以做 | 围绕上下文和工具的安全边界 |
+| **验证**   | 自动判断工具执行结果的正确性   | 围绕工具执行结果的检查机制 |
+| **纠正**   | 发现问题时自动恢复或回滚       | 围绕工具调用失败的恢复机制 |
+
+上下文和工具让智能体完成任务——理解任务并采取行动。约束、验证和纠正确保其可靠安全地完成任务——不是脱离上下文和工具，而是作为确保它们在生产中可靠工作的工程。随着智能体产品的成熟度曲线，这两组之间的重点转移。
+
+早期的智能体框架专注于上下文和工具：给模型工具，给它上下文，让它完成任务。生产级系统已将重心转移到约束、验证和纠正：确保工具调用安全，上下文得到管理，错误可恢复。
+
+以Claude Code为例。它的绝大多数框架代码都用于约束、验证和纠正，而非上下文和工具——工具本身（文件读写、命令执行、搜索）只是很小一部分；围绕它们构建的保障才是真正的核心。这些机制包括：
+
+- **进程状态管理**：跟踪智能体当前执行的步骤
+- **多层上下文压缩**：信息过多时自动修剪
+- **权限分类**：控制哪些操作需要用户确认
+- **断路器**：重复错误后自动停止重试，防止一个失败操作级联影响整个系统
+- **错误恢复机制**：捕获异常，回滚到最后稳定状态，重试或移交人类处理
+
+**行业正在从任务完成为可靠任务完成转变，使框架工程成为智能体系统的核心竞争力。**
+
+### 从提示词工程到循环工程：工程范式的演进
+
+回顾人工智能应用工程的发展，出现了清晰的演进弧线：
+
+**软件工程**是基础——传统系统设计、架构、测试和部署。**提示词工程**是第一波创新——通过优化喂给模型的自然语言指令提高输出质量。**上下文工程**是第二波——意识到仅优化提示词不够：模型的工作上下文（系统指令、工具定义、对话历史、外部知识）必须系统管理。**框架工程**是第三波——将视角从“模型接收什么信息”拓宽到“模型运行在什么样的系统中”，纳入模型之外的所有基础设施：约束机制、验证方法、反馈循环、错误恢复。**循环工程**紧随其后，将视角从单次运行拓宽到跨运行的持续自主操作：谁发现下一个工作，何时验证，何时任务才算真正完成（第10章与多智能体协作系统一起发展此内容）。
+
+2026年7月，行业开始使用**图工程**从更高层次的编排视角：将智能体循环、确定性程序和人类审批组织成显式的执行图，其中节点提供能力，边定义路由和依赖，结构化状态沿边传递并在关键边界持久化。[^ch1-graph-engineering]图工程不是循环工程的替代，也不应简单视为上述演进中的“第六层”。循环本身就是带有回边的图，图中的节点仍可以内部运行ReAct或其他智能体循环。名称尚未稳定，因此本书将其视为现有编排和框架实践的新兴术语；第10章发展多智能体部分。这里的“图”指控制流或执行图，而非GraphRAG使用的知识图。
+
+[^ch1-graph-engineering]: Josh C. Simmons在2026年7月4日的文章《我们进入图工程阶段》中明确使用了该名称，用节点、类型边和检查点状态进行总结。7月18日，Peter Steinberger关于讨论是否从循环转向图的问题帮助该名称进一步传播。这些实践早于标签出现：LangGraph、微软智能体框架和谷歌ADK的官方文档将它们描述为图编排或基于图的工作流。见https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase，https://x.com/steipete/status/2078277297791189132，https://docs.langchain.com/oss/python/langgraph/overview，https://learn.microsoft.com/en-us/agent-framework/workflows/，以及https://adk.dev/workflows/。
+
+这五个阶段不是替代关系，而是嵌套层：提示词工程是上下文工程的子集，上下文工程是框架工程的子集，框架工程是循环工程的子集。每层都拓宽了工程师的关注范围和影响力。**随着模型在能力上趋同，不再是决定性差异因素，竞争力转移到模型之外的工程。** 最近的工程实践支持这一观点。LangChain在Terminal Bench 2.0（评估智能体在终端环境中完成复杂任务能力的基准）上的工作是一个显著示例：他们的编码智能体从52.8%提高到66.5%（从排行榜前30名外跃升至前5名）。改变的不是模型，而是框架——让智能体检查自己的执行结果，检测何时陷入重复循环，并完善其推理策略。OpenAI的工程团队分享了类似经验：3名工程师在5个月内完成了约100万行代码和近1500个PR，约为传统开发速度的10倍。主要驱动力不是更强的模型；而是正确的框架。
+
+### 框架五个功能的核心原则
+
+前面的表格列出了框架的五个功能。下表添加每个功能的核心设计原则及本书的处理位置，将概念映射到实践：
+
+| 功能     | 核心原则                         | 实践示例                     | 见章 |
+|----------|----------------------------------|------------------------------|------|
+| **上下文** | 信息充分性：确保智能体在每个决策点基于充分信息做决策 | 系统提示词、知识库、智能体状态栏、Sidecar旁路查询 | 第2章和第3章 |
+| **工具**   | 接口清晰：工具名称直观，参数有示例，边界有解释     | MCP工具、代码解释器、搜索工具 | 第4章 |
+| **约束**   | 故障安全默认：所有能力默认关闭，必须显式启用（类似移动应用权限管理） | 在Claude Code中，每个工具默认执行前需用户授权 | 第4章 |
+| **验证**   | 输入隔离：安全检查仅看结构化数据（例如工具返回的JSON字段），不看模型生成的自由格式文本（因为攻击者可能通过提示注入操纵模型输出） | 代码检查器、类型系统、工具调用结果验证 | 第5章和第6章 |
+| **纠正**   | 确认无法恢复前不暴露中间状态（例如静默重试失败的工具调用，而非向用户显示未完成的结果） | 静默重试、继续生成、连续失败后移交人类判断（断路器机制） | 第2章和第5章 |
+
+五个功能形成闭环：上下文和工具支持决策，约束防止错误，验证检测偏差，纠正闭合循环。如果任何环节缺失，系统就会出现可靠性缺口。在检查具体编排模式和护栏设计之前，我们首先列出构建有效智能体的核心原则和选择模型的原则——后续所有设计决策的基础。
+
+### 构建有效智能体的核心原则
+
+基于Anthropic的经验，成功的智能体系统遵循三个核心原则。
+
+**保持简单。** 从最简单的解决方案开始，仅在真正必要时添加复杂性。直接API调用优于复杂框架；清晰代码优于巧妙抽象——每一层额外抽象都是调试时的新盲点。
+
+**保持透明。** 清晰展示智能体的规划步骤、执行日志和决策轨迹。这不仅是调试便利；它是用户信任的前提——黑盒内的错误难以从外部定位或修复。
+
+**设计良好结构的工具接口（ACI，智能体-计算机接口）。** ACI意味着从智能体的角度设计接口——易于智能体理解和使用，而非传统API中的程序员角度。工具名称和参数应直观，在可能滥用的地方设计应从一开始就使错误不可能发生：SIM卡的缺口角使其只能以一种方向滑入托盘，微波炉门打开时拒绝加热。制造业将此称为“设计消除错误”理念**防错法**，源自丰田生产系统的术语。设计不佳的工具甚至会导致最强模型反复失败：接口是模型和工具之间的唯一通道，模糊的接口会放大为系统性错误。
+
+接下来的三个部分讨论框架工程中三个独立但重要的主题：模型选择、编排模式、护栏和安全。它们不属于五个框架元素本身，但在工程实践中不可避免。
+
+### 如何选择模型
+
+在讨论编排模式之前，我们首先需要回答一个实际问题：你的智能体应该驱动哪种模型？
+
+模型是智能体智能的基础，选择合适的模型往往比任何数量的提示词调整更重要。模型发布速度太快，特定版本推荐难以保持有用，因此本节提供方向而非具体推荐。</think># 人工智能智能体入门 [第3部分/共5部分]
+
+Kimi K3在智能体任务中的显著优势是**长链工具调用的稳定性**——它可在整个过程中持续进行200-300次连续工具调用，且推理连贯，远超大多数模型开始退化时的几十次调用。K3针对长视野编程和智能体工作负载优化，发布两种变体：K3 Max（用于对话和智能体任务）与K3 Swarm Max（用于大规模并行处理）。作为开源模型，其在软件工程和智能体基准测试中可与顶级闭源系统媲美，证明强化学习可赋予模型原生智能体能力。
+
+#### 实验1-3 ★：GPT-5.6原生深度研究能力
+
+第二个实验用**OpenAI GPT-5.6**展示，由API级内置工具支持的先进模型如何在服务器端闭合“搜索—阅读—分析”编排循环以进行深度研究。GPT-5.6有三种变体——Sol（旗舰前沿模型）、Terra（日常工作平衡模型）、Luna（快速经济轻量模型），均将工具调用决策原生交由模型，客户端无需自建编排框架。其一便捷功能是**自由格式工具调用**。传统上模型调用工具需将参数序列化为严格JSON（结构化数据格式），类似按严格格式填表。自由格式工具调用（通过API中`type: "custom"`工具声明）允许模型直接向工具发送原始文本（如Python代码片段、SQL查询），完全避免JSON转义。需强调这是API参数格式演进，非模型架构创新——客户端工具调用循环（检测`tool_calls`→执行→返回结果）不变，仅参数从JSON字符串变为原始文本。GPT-5.6还引入详细程度参数（控制输出细节）和推理努力参数（调整推理深度；Sol增设最彻底推理时间最大级别），供开发者依任务复杂度调整模型行为。
+
+GPT-5.6搭配Responses API的**网络搜索与代码解释器**内置工具，具备深度研究核心机制：模型可自主搜索网络获取实时信息并编写代码深入分析，实现“搜索→阅读→分析→再次搜索”迭代研究过程。例如，面对“东盟10国首都间最短距离是多少？”，GPT-5.6会自动搜索各首都地理坐标，编写Python代码计算所有首都对大圆距离，最终确定最近一对。又如“搜索比特币过去一月趋势并进行技术分析”任务，它可从多金融数据源获取实时价格数据，用专业技术分析库计算移动平均线、RSI、MACD等指标，生成可视化图表并提供交易建议。
+
+更重要的是，GPT-5.6在模型层面内化OpenAI深度研究产品设计理念，引入**意图澄清过程**。收到研究请求时，GPT-5.6不立即执行，而是通过一系列问题澄清用户真实意图。如“搜索比特币过去一月趋势并进行技术分析”，它会先问“偏好哪个数据源？希望分析哪些技术指标？”，此交互式澄清使生成的研究报告更精准，贴合用户实际需求。
+
+GPT-5.6是“模型即智能体”的成熟示例——网络搜索、代码解释器及Responses API其他内置工具在服务器端闭环执行；编排循环从客户端转移至API服务器，简化客户端实现。模型仍发出标准工具调用，客户端不再需自建“搜索—阅读—分析”编排框架。其显著之处在于意图澄清机制：模型不即刻执行任务，而是先确认用户真正需求，再制定研究策略，在执行前弥合“用户所言”与“用户真正所需”的差距。
+
+图1-4展示“模型即智能体”范式下原生工具调用完整架构，及Kimi K3与GPT-5.6在实际任务中的ReAct执行过程。
+
+![图1-4：“模型即智能体”架构——原生工具调用](images/fig1-4.svg)
+
+## 框架工程：超越模型的竞争力
+
+至此，你已了解智能体核心工作原理：大语言模型在上下文引导下运行ReAct循环，借工具完成任务。上述实验表明基本机制可行，但也暴露脆弱性：模型可能幻觉（发明不存在的工具或参数）、选错工具或无法从错误中恢复。从工作演示到可靠产品差距显著，而框架工程正是解决这些脆弱性。本章前半部分回答智能体是什么，后半部分回答智能体如何在生产中可靠运行。
+
+前文建立核心公式：**智能体=大语言模型+上下文+工具**，描述智能体**内部组成**：推理引擎、工作上下文、行动接口。框架工程为同一系统添加**实现层面**视图：将大语言模型视为核心组件（模型），围绕它的所有支持代码为框架。两视图非竞争关系，而是不同抽象层次描述同一系统。因框架工程原则适用于任何能推理和调用工具的模型，故用更通用“模型”一词。框架核心是原始公式的“上下文+工具”，加三层保障：**约束**（智能体可做与不可做之事）、**验证**（是否正确完成事）、**纠正**（出错时如何恢复）。
+
+展开为等式，完整生产级组成为：
+
+> **智能体=大语言模型+[上下文+工具+约束+验证+纠正]=模型+框架**
+
+最小化工作智能体仅靠大语言模型、上下文、工具运行。要在长时生产负载中可靠运行，还需三层工程层——约束防越界、验证捕错误、纠正复失败。这些层非事后添加模块，而是围绕“上下文+工具”的保障。即最小公式是演示视图，扩展公式是生产视图，后者含前者并加安全网。
+
+以示例阐明边界：将退款政策嵌入上下文属**上下文**，检查退款额不超订单总额属**约束**。执行API调用属**工具**，API超时后自动重试属**纠正**。模型供底层理解与推理，框架引导、约束并放大能力以可靠完成任务。模型外设计优化此基础设施的工程实践即**框架工程**。
+
+一具体例显框架价值：要求智能体退还用户3天前订单。**无框架**：模型无退款政策（无上下文）、不知调何API（无工具）、伪造退款结果（无验证）、用户发现退款未发生（无纠正）。**有框架**：系统提示词指定7天退款政策（上下文），智能体调用`query_order`与`process_refund`工具操作（工具），框架检退款不超订单总额（约束）、与数据库确认退款完成（验证）、API超时自动重试（纠正）。同一模型，结果大异。
+
+简言之，无框架模型能力强，但缺可靠完成任务的周围控制。
+
+更精确言，模型外所有基础设施属框架。框架核心是上下文与工具，围绕其建三种工程保障：
+
+| 功能     | 一句话职责                     | 与上下文/工具关系 |
+|----------|--------------------------------|---------------------|
+| **上下文** | 为模型提供相关信息             | 核心能力            |
+| **工具**   | 为模型提供行动接口             | 核心能力            |
+| **约束**   | 设置行为边界——可做与不可做     | 围绕上下文工具的安全边界 |
+| **验证**   | 自动判工具执行结果正确性       | 围绕工具执行结果的检查机制 |
+| **纠正**   | 发现问题自动恢复或回滚         | 围绕工具调用失败的恢复机制 |
+
+上下文与工具使智能体完成任务（理解任务并行动），约束、验证、纠正保其可靠安全完成任务，非脱离上下文工具，而是确保其生产可靠工作的工程。随智能体产品成熟，两组重点转移。
+
+早期框架聚焦上下文与工具：给模型工具、上下文，令其完成任务。生产级系统重心转至约束、验证、纠正：保工具调用安全、上下文管理、错误可恢复。
+
+以Claude Code为例，其多数框架代码用于约束、验证、纠正，非上下文工具——工具本身（文件读写、命令执行、搜索）占比小，围绕其的保障是核心。机制包括：
+
+- **进程状态管理**：跟踪智能体当前执行步骤
+- **多层上下文压缩**：信息过多时自动修剪
+- **权限分类**：控哪些操作需用户确认
+- **断路器**：重复错误后自动停重试，防一失败级联影响系统
+- **错误恢复机制**：捕异常、回滚至最后稳定态、重试或移交人类处理
+
+**行业从任务完成为可靠任务完成转变，框架工程成智能体系统核心竞争力。**
+
+### 从提示词工程到循环工程：工程范式演进
+
+回顾人工智能应用工程发展，现清晰演进弧线：
+
+**软件工程**是基础——传统系统设计、架构、测试、部署。**提示词工程**是第一波创新——优化喂模型的自然语言指令提输出质量。**上下文工程**是第二波——知仅优化提示词不够，模型工作上下文（系统指令、工具定义、对话历史、外部知识）需系统管理。**框架工程**是第三波——视角从“模型收何信息”拓宽至“模型运行何系统”，纳模型外所有基础设施：约束机制、验证方法、反馈循环、错误恢复。**循环工程**继之，视角从单次运行拓至跨运行持续自主操作：谁发现下工作、何时验证、何时任务算真正完成（第10章与多智能体协作系统发展此）。
+
+2026年7月，行业用**图工程**从更高编排视角：将智能体循环、确定性程序、人类审批组织成显式执行图，节点供能力，边定义路由依赖，结构化状态沿边传递并在关键边界持久化。[^ch1-graph-engineering]图工程非循环工程替代，亦非上述演进“第六层”，循环本身是带回边的图，图中节点可内部运行ReAct等智能体循环。名称未稳，本书视其为现有编排框架实践新兴术语；第10章发展多智能体部分。此处“图”指控制流或执行图，非GraphRAG的知识图。
+
+[^ch1-graph-engineering]: Josh C. Simmons 2026年7月4日文章《我们进入图工程阶段》明确用此名，以节点、类型边、检查点状态总结。18日Peter Steinberger关于讨论从循环转图的问题助其传播。实践早于标签：LangGraph、微软智能体框架、谷歌ADK官方文档称其为图编排或基于图工作流。见https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase，https://x.com/steipete/status/2078277297791189132，https://docs.langchain.com/oss/python/langgraph/overview，https://learn.microsoft.com/en-us/agent-framework/workflows/，https://adk.dev/workflows/。
+
+五阶段非替代，乃嵌套层：提示词工程是上下文工程子集，上下文工程是框架工程子集，框架工程是循环工程子集，每层拓宽工程师关注影响力。**随模型能力趋同，非决定性差异，竞争力转至模型外工程。** 近期工程实践证此，LangChain Terminal Bench 2.0（评估智能体终端复杂任务能力基准）工作为显例：其编码智能体从52.8%提至66.5%（从榜前30外跃至前5），变的非模型，而是框架——智能体检自身执行结果、检测重复循环、完善推理策略。OpenAI工程团队经验类似：3工程师5月完成约100万行代码、近1500个PR，约传统速度10倍，主因非更强模型，而是正确框架。
+
+### 框架五功能核心原则
+
+前文表格列框架五功能，下表加各功能核心设计原则及本书处理位置，映射概念至实践：
+
+| 功能     | 核心原则                         | 实践示例                     | 见章 |
+|----------|----------------------------------|------------------------------|------|
+| **上下文** | 信息充分性：确保智能体决策点基于充分信息 | 系统提示词、知识库、智能体状态栏、Sidecar旁路查询 | 第2、3章 |
+| **工具**   | 接口清晰：工具名直观、参数有示例、边界有解释 | MCP工具、代码解释器、搜索工具 | 第4章 |
+| **约束**   | 故障安全默认：所有能力默认关闭，须显式启用（类移动应用权限管理） | Claude Code中工具默认执行前需用户授权 | 第4章 |
+| **验证**   | 输入隔离：安全检查仅看结构化数据（如工具返回JSON字段），不看模型自由格式文本（防提示注入操纵） | 代码检查器、类型系统、工具调用结果验证 | 第5、6章 |
+| **纠正**   | 确认不可恢复前不暴露中间状态（如静默重试失败工具调用，不向用户显未完成结果） | 静默重试、继续生成、连续失败移交人类判断（断路器机制） | 第2、5章 |
+
+五功能成闭环：上下文工具支持决策，约束防错，验证检偏差，纠正闭循环。环节缺失则系统现可靠性缺口。在检具体编排模式护栏设计前，先列构建有效智能体核心原则及选模型原则——后续设计决策基础。
+
+### 如何选择模型
+
+讨论编排模式前，先答实际问题：智能体应驱哪种模型？
+
+模型是智能体智能基础，选合适模型常比提示词调整重要。模型更新快，特定版本推荐难持久，故本节给方向非具体推荐。

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/getting_started_with_ai_agents_part_4_5_zh.md

@@ -0,0 +1,258 @@
+用户现在需要翻译第四章的内容，我需要逐句准确翻译。首先开头是“# Getting Started with AI Agents [Part 4/5]”，翻译为“# 人工智能智能体入门 [第4部分/共5部分]”。然后逐段处理，注意专业术语的准确，比如“Know the 'Big Three.'”翻译为“了解‘三大巨头’”，还有各个模型提供商的名称和特点要准确翻译。要确保语句通顺，符合中文技术文档的表达习惯。现在开始逐句翻译：
+
+# 人工智能智能体入门 [第4部分/共5部分]
+
+**了解“三大巨头”**。当前智能体开发中最常用的三家闭源模型提供商是OpenAI（GPT/o系列）、Anthropic（Claude系列）和谷歌（Gemini系列）。各有优势：Claude擅长复杂推理、编码和工具调用，是智能体开发的热门选择；Gemini提供超长上下文窗口和强大的多模态能力，适合长文本及图像、视频等多媒体场景；GPT/o系列能力均衡，用户基数最大。选择模型时，不要仅依赖排行榜；**在自己的任务上进行评估**（见第6章）。
+
+**中国模型**。如果应用部署在中国或预算紧张，中国厂商的模型是务实之选。字节跳动的豆包系列在中国内延迟极低，适合实时交互；月之暗面的Kimi在智能体能力上是较强的中国模型之一；通义千问、深度求索等开源模型在成本和可定制性上有优势。注意不同模型的工具调用能力差异较大，务必在具体场景中测试后再选用。中国模型通常通过火山引擎（豆包）、硅基智能（开源模型）等平台的API访问，非中国模型可通过OpenRouter等聚合服务访问。
+
+**开源 vs. 闭源**。闭源模型通常能力领先，但成本更高且受厂商API政策约束。开源模型成本低、支持私有部署、允许微调定制，适合成本敏感场景或有数据合规要求的场景。
+
+**大多数智能体需要支持推理的模型**。智能体进行复杂决策——多步骤推理、工具选择等，不支持推理的模型在这类任务中表现较差。少数例外：单一简单步骤，或相当于点击固定位置的计算机使用GUI操作，此时非推理模型可能够用。一旦涉及多步骤推理或动态决策，推理模型必不可少。
+
+**考虑输出速度和多模态能力**。除成本外，有两个维度易被忽视。一是**输出令牌速度**：智能体通常要运行多轮推理，每轮必须在前一轮完成后才能开始，因此输出速度直接决定端到端延迟——20轮的智能体任务每轮慢2秒，意味着额外等待40秒。二是**多模态支持**：若智能体需理解图像、音频或视频，多模态能力是硬性要求，不同模型在此方面差异较大。
+
+### 编排模式：工作流与自主式
+
+编排模式是框架组织其“上下文与工具”层的方式——决定LLM调用间上下文如何流动、工具如何调度、智能体执行路径是预先固定还是动态生成。智能体编排从简单到复杂演进，每种模式有适用用例和权衡。根据Anthropic与数十个构建LLM智能体团队的合作经验，最成功的实现极少使用复杂框架，而是采用简单、可组合的模式。
+
+构建LLM应用时，从简单到复杂推进。先从单次LLM调用开始——若更好的提示词和上下文示例能解决问题，无需构建智能体系统。当需要多步骤且任务可清晰分解为固定子任务时，使用工作流。仅当需要动态决策和灵活执行路径时，使用自主式智能体。且需记住：智能体系统通常以牺牲延迟和成本为代价换取更好任务性能——需仔细评估该权衡是否值得。
+
+#### 工作流模式：确定性编排
+
+**工作流**是通过预定义代码路径编排LLM和工具的系统。其执行路径是确定性的，由开发者预先设计——每一步骤和转换的行为在代码中定义；LLM仅处理每个节点内的理解和生成。
+
+例如，一个航班预订智能体可使用包含四个固定节点的工作流：
+
+1. **验证用户身份**——调用身份验证API确认用户身份。
+2. **搜索可用航班**——根据用户需求查询航班数据库。
+3. **完成支付**——调用支付接口扣款。
+4. **确认预订**——调用预订API锁定座位并向用户发送确认。
+
+每个节点内可使用LLM（例如用自然语言理解用户出行需求），但节点间的流程顺序由代码固定——系统不会在支付完成前预订座位，也不会在身份验证前开始搜索航班。
+
+工作流模式有两个核心优势。首先，**严格流程控制**：开发者可保证关键步骤绝不被跳过或乱序运行——“支付前不预订”等业务规则由代码强制执行，而非交由LLM判断。其次，**安全性**：由于执行路径是确定性的，提示注入或模型错误最多影响当前节点内的处理；无法使智能体跳转到不应到达的分支。攻击面局限于单个节点。
+
+工作流模式的主要局限是**缺乏灵活性**。当出现意外事件时——例如用户在支付时更改预订，或航班取消需系统推荐替代方案——固定路径无法自行适应；只能遵循预设的异常分支或将控制权交回人类。
+
+#### 自主式智能体：运行时决策
+
+当工作流的固定路径不足时，需要**自主式智能体**。自主式智能体与工作流的核心区别在于，执行路径不是预先定义的，而是由智能体根据**环境反馈**在运行时决定。
+
+回到航班示例，自主式智能体无需四个预定义节点。用户说“给我预订下周三去上海的航班”，智能体动态确定顺序：搜索航班，发现需登录，验证身份，继续搜索。若最便宜的航班有经停，可询问是否接受；若用户说不，调整搜索标准。
+
+因此，自主式智能体必须自行规划——选择自身执行步骤，并识别失败和改变策略，而非仅在错误时停止。但自主性非无界：必须设计明确的**停止条件**（任务完成、达到最大迭代次数、遇到不可恢复错误），否则智能体可能进入无限循环或在任务已完成后继续执行。
+
+从实现角度看，自主式智能体本质是在循环中使用工具的LLM，不断获取环境反馈以推进任务——这是前文介绍的ReAct循环。常见退出条件包括：调用最终输出工具、模型返回无任何工具调用的响应，或遇到错误或达到最大轮次。
+
+![图1-5：自主式智能体执行循环](images/fig1-5.svg)
+
+自主式智能体非常适合开放式问题——难以或无法预测所需步骤数的问题。典型用例包括：解决SWE-bench（软件工程基准，评估智能体自动修复真实GitHub问题能力的基准）任务的编码智能体、像人类一样操作计算机界面的“计算机使用”智能体、需要迭代搜索分析的研究任务。
+
+自主式智能体成本更高，且错误会累积。因此部署自主式智能体需在沙盒中 thorough 测试、适当设置护栏和监控，并在关键决策点设置人工参与检查点。
+
+#### 选择并混合两种模式
+
+实践中，工作流和自主式智能体并非互斥——许多系统混合两者：有严格合规要求的关键流程以工作流运行保证可靠性，需要灵活决策的部分切换为自主式模式。例如，n8n是成熟的开源工作流自动化框架，开发者通过在可视化画布上排列功能组件构建智能体——工作流节点和自主式智能体节点可在同一系统中共存。
+
+![图1-6：n8n工作流编辑器界面](images/n8n-workflow.png)
+
+#### 主流智能体框架简要对比
+
+下表总结广泛使用的智能体框架和平台，帮助读者识别适合自身场景的框架：
+
+| 框架聚焦       | 对应章节               | 核心内容                             | 安全关注点               |
+|----------------|------------------|------------------------------------------|---------------------------|
+| 上下文设计     | 第2章（上下文工程）   | 提示词工程、智能体状态栏、上下文压缩、智能体技能 | 提示注入和信息泄露       |
+| 上下文扩展（知识持久化） | 第3章（知识库）     | 用户记忆、RAG、结构化索引、智能体化RAG | 敏感信息暴露、隐私保护   |
+| 工具设计与安全约束 | 第4章（工具设计）   | 工具分类、权限控制、MCP标准、异步架构 | 误操作、未授权访问、不可逆操作 |
+| 工具验证与纠正 | 第5章（代码生成）   | 编码智能体框架、测试驱动开发、编码规则 | 身份冒充、责任归属       |
+| 系统级验证     | 第6章（评估）       | 评估环境、数据集、自动化评估、可观测性 | —                         |
+| 模型级纠正     | 第7章（后训练）     | SFT（监督微调）、强化学习——将框架中积累的反馈信号写入模型参数，可视为框架工程的扩展 | 目标偏离、对齐和鲁棒性   |
+| 经验驱动的持续纠正 | 第8章（持续演进） | 轨迹学习信号；知识/指令/程序/参数更新；自我修改；验证与回滚 | —                         |
+| 多模态上下文与工具 | 第9章（多模态与实时交互） | 语音智能体、计算机使用、机器人操作 | 多模态输入的安全过滤、实时交互中的权限控制 |
+| 多智能体间的约束与纠正 | 第10章（多智能体协作） | 协作架构、失败模式、智能体社会       | 智能体间的信任边界违反、共享资源冲突 |
+
+随着“模型即智能体”趋势深化，框架的核心价值不再在于“编排LLM调用”——模型越来越自行决策。更重要的是模型周围的框架工程：上下文管理、工具生态、安全约束、错误恢复。选择框架时，问题不在于框架有多复杂，而在于是否能通过尽可能薄的抽象层专注于业务逻辑。
+
+编排模式解决框架内上下文与工具的组织——LLM调用、工具、数据流如何连接。但任务完成不够，还需正确安全地完成任务。因此我们转向护栏在实践中的主要实现方式：护栏。
+
+### 护栏与安全性
+
+本节从高层概述护栏，建立大局观。实现细节和实践见第2章（提示注入防护）、第4章（工具权限控制）、第5章（代码执行安全）；初次阅读无需关注所有细节。
+
+护栏是框架“约束、验证、纠正”层的主要实现方式——分层防御，保证智能体行为安全可控。设计良好的**护栏**有助于管理数据隐私风险（例如防止系统提示词泄露）和声誉风险（例如保持模型行为与品牌一致）。从已识别的风险开始设置护栏，随着新漏洞出现添加新护栏。
+
+将护栏视为深度防御。单一护栏通常不足以单独发挥作用，但多个专门护栏组合可构建更具弹性的智能体系统。
+
+#### 护栏类型
+
+根据在执行流中的位置，护栏分为三类：输入侧、执行侧、输出侧。
+
+**输入侧**护栏在请求到达智能体前拦截，通常通过四种机制。**相关性分类器**标记离题查询——例如编码助手被问“帝国大厦有多高？”。**安全分类器**检测越狱（诱导模型绕过安全限制）和提示注入（在输入中嵌入恶意指令）。关键区别：越狱中用户直接尝试绕过模型限制；提示注入中攻击者通过外部数据（网络内容、文档）间接操纵模型行为。**内容审核**标记有害或不适当输入，例如暴力或歧视性内容。**基于规则的防护**对已知威胁（例如SQL注入）应用确定性措施——黑名单、输入长度限制、正则表达式过滤。
+
+**执行侧**护栏验证工具调用。核心是**工具风险评级**：根据操作是否可逆、权限级别、财务影响，为每个工具分配风险级别（低/中/高）。高风险操作需额外审查或人类确认。
+
+**输出侧**护栏在响应返回用户前检查。**PII过滤器**审查输出中的个人身份信息（例如身份证号、电话号码）防止不必要暴露；**输出验证**通过内容检查确保回复符合品牌价值。
+
+注意，某些机制（例如基于规则的正则过滤）可在输入侧和输出侧使用；上述分类遵循最常见的部署位置。
+
+基于分类器的护栏的典型行业实践是Anthropic的宪法分类器[^ch1-3]。其设计有三个关键要素。首先，**规则驱动训练**：用自然语言编写的“宪法”——明确指定允许和不允许的内容——用于为输入和输出分类器生成合成训练数据。其次，**联合上下文判断**：新一代检查用户问题和模型答案一起，因为有些答案单独看看似正常（例如“如何使用食品调味料”），仅结合问题才发现“食品调味料”暗指化学试剂。第三，**两阶段筛选**：极轻量的探测器——几乎无成本读取模型内部激活——先检查每个对话，任何可疑内容升级到更强大的分类器审查，而非直接拒绝。这样第一阶段可容忍更多假阳性而不影响用户体验，整体成本大幅降低。
+
+[^ch1-3]: Anthropic. "Next-generation Constitutional Classifiers: More efficient protection against universal jailbreaks", 2026. https://www.anthropic.com/research/next-generation-constitutional-classifiers; paper: Cunningham et al., "Constitutional Classifiers++: Efficient Production-Grade Defenses against Universal Jailbreaks", arXiv:2601.04603
+
+#### 人类干预
+
+**人工参与**是关键防护措施：它让智能体在不降低用户体验的情况下提升真实世界性能。在早期部署中尤其重要，帮助识别失败模式、暴露边缘案例、建立稳健的评估循环。
+
+有人工参与机制时，无法完成任务的智能体可优雅地移交控制权。在客户服务中，意味着升级到人类代表；对于编码智能体，意味着将控制权交回开发者。
+
+通常有两种主要情况触发人类干预：
+
+**超过失败阈值**
+设置智能体重试和操作的上限。若智能体超过该上限（例如多次尝试仍无法推断客户意图），升级到人类。
+
+**高风险操作**
+敏感、不可逆或高风险操作应触发人类监督——至少在团队对智能体可靠性建立足够信心前。典型示例：取消用户订单、授权大额退款、处理支付。
+
+牢记框架的五个功能，本书其余部分按此结构展开。
+
+### 本书作为框架工程的实用指南
+
+从框架工程视角看，本书每一章系统构建框架的一个组件。安全性则不属于单一章节，而是贯穿全书的横切关注点（横切关注点同时触及系统多个部分——软件工程中日志需贯穿每个模块的方式）。下表将框架功能、安全方面和对应章节整合呈现：
+
+| 框架聚焦       | 对应章节               | 核心内容                             | 安全关注点               |
+|--------------------|------------------|------------------------------------------|------------------------|
+| 上下文设计     | 第2章（上下文工程）   | 提示词工程、智能体状态栏、上下文压缩、智能体技能 | 提示注入和信息泄露       |
+| 上下文扩展（知识持久化） | 第3章（知识库）     | 用户记忆、RAG、结构化索引、智能体化RAG | 敏感信息暴露、隐私保护   |
+| 工具设计与安全约束 | 第4章（工具设计）   | 工具分类、权限控制、MCP标准、异步架构 | 误操作、未授权访问、不可逆操作 |
+| 工具验证与纠正 | 第5章（代码生成）   | 编码智能体框架、测试驱动开发、编码规则 | 身份冒充、责任归属       |
+| 系统级验证     | 第6章（评估）       | 评估环境、数据集、自动化评估、可观测性 | —                         |
+| 模型级纠正     | 第7章（后训练）     | SFT（监督微调）、强化学习——将框架中积累的反馈信号写入模型参数，可视为框架工程的扩展 | 目标偏离、对齐和鲁棒性   |
+| 系统级纠正     | 第8章（自我演进） | 外部化学习、工具创建、经验积累       | —                         |
+| 多模态上下文与工具 | 第9章（多模态与实时交互） | 语音智能体、计算机使用、机器人操作 | 多模态输入的安全过滤、实时交互中的权限控制 |
+| 多智能体间的约束与纠正 | 第10章（多智能体协作） | 协作架构、失败模式、智能体社会       | 智能体间的信任边界违反、共享资源冲突 |</think># 人工智能智能体入门 [第4部分/共5部分]
+
+### 了解“三大巨头”
+当前智能体开发中最常用的三家闭源模型提供商是OpenAI（GPT/o系列）、Anthropic（Claude系列）和谷歌（Gemini系列）。各有优势：Claude擅长复杂推理、编码和工具调用，是智能体开发的热门选择；Gemini提供超长上下文窗口和强大的多模态能力，适合长文本及图像、视频等多媒体场景；GPT/o系列能力均衡，用户基数最大。选择模型时，不要仅依赖排行榜；**在自己的任务上进行评估**（见第6章）。
+
+### 中国模型
+如果应用部署在中国或预算紧张，中国厂商的模型是务实之选。字节跳动的豆包系列在中国内延迟极低，适合实时交互；月之暗面的Kimi在智能体能力上是较强的中国模型之一；通义千问、深度求索等开源模型在成本和可定制性上有优势。注意不同模型的工具调用能力差异较大，务必在具体场景中测试后再选用。中国模型通常通过火山引擎（豆包）、硅基智能（开源模型）等平台的API访问，非中国模型可通过OpenRouter等聚合服务访问。
+
+### 开源 vs. 闭源
+闭源模型通常能力领先，但成本更高且受厂商API政策约束。开源模型成本低、支持私有部署、允许微调定制，适合成本敏感场景或有数据合规要求的场景。
+
+### 大多数智能体需要支持推理的模型
+智能体进行复杂决策——多步骤推理、工具选择等，不支持推理的模型在这类任务中表现较差。少数例外：单一简单步骤，或相当于点击固定位置的计算机使用GUI操作，此时非推理模型可能够用。一旦涉及多步骤推理或动态决策，推理模型必不可少。
+
+### 考虑输出速度和多模态能力
+除成本外，有两个维度易被忽视。一是**输出令牌速度**：智能体通常要运行多轮推理，每轮必须在前一轮完成后才能开始，因此输出速度直接决定端到端延迟——20轮的智能体任务每轮慢2秒，意味着额外等待40秒。二是**多模态支持**：若智能体需理解图像、音频或视频，多模态能力是硬性要求，不同模型在此方面差异较大。
+
+### 编排模式：工作流与自主式
+编排模式是框架组织其“上下文与工具”层的方式——决定LLM调用间上下文如何流动、工具如何调度、智能体执行路径是预先固定还是动态生成。智能体编排从简单到复杂演进，每种模式有适用用例和权衡。根据Anthropic与数十个构建LLM智能体团队的合作经验，最成功的实现极少使用复杂框架，而是采用简单、可组合的模式。
+
+#### 工作流模式：确定性编排
+**工作流**是通过预定义代码路径编排LLM和工具的系统。其执行路径是确定性的，由开发者预先设计——每一步骤和转换的行为在代码中定义；LLM仅处理每个节点内的理解和生成。
+
+例如，一个航班预订智能体可使用包含四个固定节点的工作流：
+1. **验证用户身份**——调用身份验证API确认用户身份。
+2. **搜索可用航班**——根据用户需求查询航班数据库。
+3. **完成支付**——调用支付接口扣款。
+4. **确认预订**——调用预订API锁定座位并向用户发送确认。
+
+每个节点内可使用LLM（例如用自然语言理解用户出行需求），但节点间的流程顺序由代码固定——系统不会在支付完成前预订座位，也不会在身份验证前开始搜索航班。
+
+工作流模式有两个核心优势。首先，**严格流程控制**：开发者可保证关键步骤绝不被跳过或乱序运行——“支付前不预订”等业务规则由代码强制执行，而非交由LLM判断。其次，**安全性**：由于执行路径是确定性的，提示注入或模型错误最多影响当前节点内的处理；无法使智能体跳转到不应到达的分支。攻击面局限于单个节点。
+
+工作流模式的主要局限是**缺乏灵活性**。当出现意外事件时——例如用户在支付时更改预订，或航班取消需系统推荐替代方案——固定路径无法自行适应；只能遵循预设的异常分支或将控制权交回人类。
+
+#### 自主式智能体：运行时决策
+当工作流的固定路径不足时，需要**自主式智能体**。自主式智能体与工作流的核心区别在于，执行路径不是预先定义的，而是由智能体根据**环境反馈**在运行时决定。
+
+回到航班示例，自主式智能体无需四个预定义节点。用户说“给我预订下周三去上海的航班”，智能体动态确定顺序：搜索航班，发现需登录，验证身份，继续搜索。若最便宜的航班有经停，可询问是否接受；若用户说不，调整搜索标准。
+
+因此，自主式智能体必须自行规划——选择自身执行步骤，并识别失败和改变策略，而非仅在错误时停止。但自主性非无界：必须设计明确的**停止条件**（任务完成、达到最大迭代次数、遇到不可恢复错误），否则智能体可能进入无限循环或在任务已完成后继续执行。
+
+从实现角度看，自主式智能体本质是在循环中使用工具的LLM，不断获取环境反馈以推进任务——这是前文介绍的ReAct循环。常见退出条件包括：调用最终输出工具、模型返回无任何工具调用的响应，或遇到错误或达到最大轮次。
+
+![图1-5：自主式智能体执行循环](images/fig1-5.svg)
+
+自主式智能体非常适合开放式问题——难以或无法预测所需步骤数的问题。典型用例包括：解决SWE-bench（软件工程基准，评估智能体自动修复真实GitHub问题能力的基准）任务的编码智能体、像人类一样操作计算机界面的“计算机使用”智能体、需要迭代搜索分析的研究任务。
+
+自主式智能体成本更高，且错误会累积。因此部署自主式智能体需在沙盒中 thorough 测试、适当设置护栏和监控，并在关键决策点设置人工参与检查点。
+
+#### 选择并混合两种模式
+实践中，工作流和自主式智能体并非互斥——许多系统混合两者：有严格合规要求的关键流程以工作流运行保证可靠性，需要灵活决策的部分切换为自主式模式。例如，n8n是成熟的开源工作流自动化框架，开发者通过在可视化画布上排列功能组件构建智能体——工作流节点和自主式智能体节点可在同一系统中共存。
+
+![图1-6：n8n工作流编辑器界面](images/n8n-workflow.png)
+
+#### 主流智能体框架简要对比
+下表总结广泛使用的智能体框架和平台，帮助读者识别适合自身场景的框架：
+
+| 框架聚焦       | 对应章节               | 核心内容                             | 安全关注点               |
+|----------------|------------------|------------------------------------------|---------------------------|
+| 上下文设计     | 第2章（上下文工程）   | 提示词工程、智能体状态栏、上下文压缩、智能体技能 | 提示注入和信息泄露       |
+| 上下文扩展（知识持久化） | 第3章（知识库）     | 用户记忆、RAG、结构化索引、智能体化RAG | 敏感信息暴露、隐私保护   |
+| 工具设计与安全约束 | 第4章（工具设计）   | 工具分类、权限控制、MCP标准、异步架构 | 误操作、未授权访问、不可逆操作 |
+| 工具验证与纠正 | 第5章（代码生成）   | 编码智能体框架、测试驱动开发、编码规则 | 身份冒充、责任归属       |
+| 系统级验证     | 第6章（评估）       | 评估环境、数据集、自动化评估、可观测性 | —                         |
+| 模型级纠正     | 第7章（后训练）     | SFT（监督微调）、强化学习——将框架中积累的反馈信号写入模型参数，可视为框架工程的扩展 | 目标偏离、对齐和鲁棒性   |
+| 经验驱动的持续纠正 | 第8章（持续演进） | 轨迹学习信号；知识/指令/程序/参数更新；自我修改；验证与回滚 | —                         |
+| 多模态上下文与工具 | 第9章（多模态与实时交互） | 语音智能体、计算机使用、机器人操作 | 多模态输入的安全过滤、实时交互中的权限控制 |
+| 多智能体间的约束与纠正 | 第10章（多智能体协作） | 协作架构、失败模式、智能体社会       | 智能体间的信任边界违反、共享资源冲突 |
+
+随着“模型即智能体”趋势深化，框架的核心价值不再在于“编排LLM调用”——模型越来越自行决策。更重要的是模型周围的框架工程：上下文管理、工具生态、安全约束、错误恢复。选择框架时，问题不在于框架有多复杂，而在于是否能通过尽可能薄的抽象层专注于业务逻辑。
+
+编排模式解决框架内上下文与工具的组织——LLM调用、工具、数据流如何连接。但任务完成不够，还需正确安全地完成任务。因此我们转向护栏在实践中的主要实现方式：护栏。
+
+### 护栏与安全性
+本节从高层概述护栏，建立大局观。实现细节和实践见第2章（提示注入防护）、第4章（工具权限控制）、第5章（代码执行安全）；初次阅读无需关注所有细节。
+
+护栏是框架“约束、验证、纠正”层的主要实现方式——分层防御，保证智能体行为安全可控。设计良好的**护栏**有助于管理数据隐私风险（例如防止系统提示词泄露）和声誉风险（例如保持模型行为与品牌一致）。从已识别的风险开始设置护栏，随着新漏洞出现添加新护栏。
+
+将护栏视为深度防御。单一护栏通常不足以单独发挥作用，但多个专门护栏组合可构建更具弹性的智能体系统。
+
+#### 护栏类型
+根据在执行流中的位置，护栏分为三类：输入侧、执行侧、输出侧。
+
+**输入侧**护栏在请求到达智能体前拦截，通常通过四种机制。**相关性分类器**标记离题查询——例如编码助手被问“帝国大厦有多高？”。**安全分类器**检测越狱（诱导模型绕过安全限制）和提示注入（在输入中嵌入恶意指令）。关键区别：越狱中用户直接尝试绕过模型限制；提示注入中攻击者通过外部数据（网络内容、文档）间接操纵模型行为。**内容审核**标记有害或不适当输入，例如暴力或歧视性内容。**基于规则的防护**对已知威胁（例如SQL注入）应用确定性措施——黑名单、输入长度限制、正则表达式过滤。
+
+**执行侧**护栏验证工具调用。核心是**工具风险评级**：根据操作是否可逆、权限级别、财务影响，为每个工具分配风险级别（低/中/高）。高风险操作需额外审查或人类确认。
+
+**输出侧**护栏在响应返回用户前检查。**PII过滤器**审查输出中的个人身份信息（例如身份证号、电话号码）防止不必要暴露；**输出验证**通过内容检查确保回复符合品牌价值。
+
+注意，某些机制（例如基于规则的正则过滤）可在输入侧和输出侧使用；上述分类遵循最常见的部署位置。
+
+基于分类器的护栏的典型行业实践是Anthropic的宪法分类器[^ch1-3]。其设计有三个关键要素。首先，**规则驱动训练**：用自然语言编写的“宪法”——明确指定允许和不允许的内容——用于为输入和输出分类器生成合成训练数据。其次，**联合上下文判断**：新一代检查用户问题和模型答案一起，因为有些答案单独看看似正常（例如“如何使用食品调味料”），仅结合问题才发现“食品调味料”暗指化学试剂。第三，**两阶段筛选**：极轻量的探测器——几乎无成本读取模型内部激活——先检查每个对话，任何可疑内容升级到更强大的分类器审查，而非直接拒绝。这样第一阶段可容忍更多假阳性而不影响用户体验，整体成本大幅降低。
+
+[^ch1-3]: Anthropic. "Next-generation Constitutional Classifiers: More efficient protection against universal jailbreaks", 2026. https://www.anthropic.com/research/next-generation-constitutional-classifiers; paper: Cunningham et al., "Constitutional Classifiers++: Efficient Production-Grade Defenses against Universal Jailbreaks", arXiv:2601.04603
+
+#### 人类干预
+**人工参与**是关键防护措施：它让智能体在不降低用户体验的情况下提升真实世界性能。在早期部署中尤其重要，帮助识别失败模式、暴露边缘案例、建立稳健的评估循环。
+
+有人工参与机制时，无法完成任务的智能体可优雅地移交控制权。在客户服务中，意味着升级到人类代表；对于编码智能体，意味着将控制权交回开发者。
+
+通常有两种主要情况触发人类干预：
+
+**超过失败阈值**
+设置智能体重试和操作的上限。若智能体超过该上限（例如多次尝试仍无法推断客户意图），升级到人类。
+
+**高风险操作**
+敏感、不可逆或高风险操作应触发人类监督——至少在团队对智能体可靠性建立足够信心前。典型示例：取消用户订单、授权大额退款、处理支付。
+
+牢记框架的五个功能，本书其余部分按此结构展开。
+
+### 本书作为框架工程的实用指南
+从框架工程视角看，本书每一章系统构建框架的一个组件。安全性则不属于单一章节，而是贯穿全书的横切关注点（横切关注点同时触及系统多个部分——软件工程中日志需贯穿每个模块的方式）。下表将框架功能、安全方面和对应章节整合呈现：
+
+| 框架聚焦       | 对应章节               | 核心内容                             | 安全关注点               |
+|--------------------|------------------|------------------------------------------|------------------------|
+| 上下文设计     | 第2章（上下文工程）   | 提示词工程、智能体状态栏、上下文压缩、智能体技能 | 提示注入和信息泄露       |
+| 上下文扩展（知识持久化） | 第3章（知识库）     | 用户记忆、RAG、结构化索引、智能体化RAG | 敏感信息暴露、隐私保护   |
+| 工具设计与安全约束 | 第4章（工具设计）   | 工具分类、权限控制、MCP标准、异步架构 | 误操作、未授权访问、不可逆操作 |
+| 工具验证与纠正 | 第5章（代码生成）   | 编码智能体框架、测试驱动开发、编码规则 | 身份冒充、责任归属       |
+| 系统级验证     | 第6章（评估）       | 评估环境、数据集、自动化评估、可观测性 | —                         |
+| 模型级纠正     | 第7章（后训练）     | SFT（监督微调）、强化学习——将框架中积累的反馈信号写入模型参数，可视为框架工程的扩展 | 目标偏离、对齐和鲁棒性   |
+| 系统级纠正     | 第8章（自我演进） | 外部化学习、工具创建、经验积累       | —                         |
+| 多模态上下文与工具 | 第9章（多模态与实时交互） | 语音智能体、计算机使用、机器人操作 | 多模态输入的安全过滤、实时交互中的权限控制 |
+| 多智能体间的约束与纠正 | 第10章（多智能体协作） | 协作架构、失败模式、智能体社会       | 智能体间的信任边界违反、共享资源冲突 |

chapter10/book-translation/validation/real_20260730T044233Z/single_agent_parts/getting_started_with_ai_agents_part_5_5_zh.md

@@ -0,0 +1,42 @@
+# 人工智能智能体入门 [第5部分/共5部分]
+
+Anthropic构建长时运行智能体的实践展现了框架设计如何解决模型自身无法攻克的难题。他们将复杂任务拆分为“初始化智能体”（搭建环境、分解任务列表）与“执行智能体”（每会话逐步推进并留存清晰交接工件），借助结构化框架应对长任务的两大失败情形：上下文耗尽与过早宣告任务完成。后续章节将逐个剖析框架组件——第2章从最为核心的上下文工程切入，第5章详述编码智能体中框架工程的完整实践。
+
+## 章节总结
+
+本章搭建了理解与构建人工智能智能体的实践优先框架。
+
+### 核心公式：智能体=推理引擎+工作上下文+行动接口
+大语言模型提供推理与决策能力，上下文在决策时刻提供可用的信息集合，工具提供行动接口。三者缺一不可。
+
+### 关键杠杆：扩展上下文与工具
+模型固定后，重新定义或拓展观测与行动空间（即扩展上下文与工具）往往能直接让不可解任务变为可解任务。从Manus到OpenClaw的演进印证，通用性很大程度源于接口边界的拓宽；这种扩展需按需进行，并搭配权限与验证机制。
+
+### 决定性因素：上下文
+上下文由静态前缀（系统提示词+工具定义）与动态轨迹（消息历史）构成。消融实验表明，移除任一组件都会显著削弱系统性能。ReAct循环的本质是不断向轨迹追加内容，推动模型持续推进任务。
+
+### 竞争力所在：框架
+模型能力渐趋商品化，真正的差异源于框架——围绕上下文与工具构建的约束、验证及纠正机制，保障任务可靠完成。生产级智能体系统中，绝大多数框架代码用于这些保障，而非仅聚焦上下文与工具。
+
+### 编排模式演进：从工作流到自主式智能体
+遵循先提示词、再工作流、最后自主式智能体的顺序，是减少意外行为的实用路径。每种编排模式各有适用场景，不存在放之四海而皆准的最优模式。
+
+### 安全本质：架构问题
+护栏、人工参与干预、对齐（确保模型行为与人类意图一致）需从代码伊始就进行设计，而非发布前修补。安全涵盖模型、上下文、工具、协作、社会五层。
+
+下一章将深入剖析框架最核心的组件：上下文工程。第7章探讨智能体概念在强化学习中的学术渊源，并对比传统强化学习与现代大语言模型智能体。
+
+以下思考问题旨在深化本章核心概念。
+
+## 思考问题
+
+1. ★★ 若只能为智能体系统添加一种能力——更强的模型、更丰富的上下文或更多工具，你会作何选择？在何种条件下选择会发生变化？  
+2. ★★★ ReAct循环中，智能体每次大语言模型调用均接收完整历史轨迹，随轨迹增长，该设计的成本呈二次方增长。能否在不丢失关键信息的前提下打破这种二次方增长？  
+3. ★★“模型即智能体”范式使模型在工具调用决策上愈发自主，然而本章认为框架工程的重要性实则在提升。这两种趋势如何共存？智能体框架的未来核心价值何在？  
+4. ★★ 消融实验中，缺失“工具结果反馈”致使智能体陷入无限循环。生产环境中，除缺失工具结果外，还有哪些情形会引发智能体循环？应设计何种检测与终止机制？  
+5. ★ 本章沿工作上下文、行动接口、策略三个维度分析了五种智能体产品。选取日常使用的一款人工智能产品，按相同维度分析其架构是否恰当。若由你设计，会进行哪些改进？  
+6. ★★ 若专门设计一个航班预订客户服务系统，会选择工作流模式还是自主式智能体模式？同一系统中能否混合两种模式？  
+7. ★★★ 护栏部分提及工具风险评级，若某工具通常风险低，但在特定参数组合下变为高风险（如`delete_file`删除普通文件与删除系统文件），如何设计动态风险评估？  
+8. ★★ 本章智能体产品表中所有智能体均具“开放式”行动空间，哪些场景下受限行动空间（如仅能从预定义选项中选择）优于开放式行动空间？  
+9. ★★ 人工参与干预机制要求智能体“优雅移交控制权”，但实践中用户可能离线、响应迟缓或指令模糊，此时智能体应如何应对？  
+10. ★★★ 引言提到“良好的设计原则应超越模型迭代周期”，举出一个随模型改进可能过时的当前智能体设计原则，并阐述理由。