●○○○○○○○○○
Agent 核心循环
理解 Agent 与传统 Chatbot 的根本差异：多步骤自主循环
AI Agent 的核心是一个 Perception → Think → Act → Observe 的反馈循环。与单轮对话的 Chatbot 不同，Agent 能够在多个步骤中维持上下文、制定计划并迭代改进。
核心循环的四个阶段
每个 Agent 迭代包含四个关键阶段：
1
感知 (Perception)
Agent 接收用户输入、环境信息、工具反馈等多源信息，形成对当前状态的完整理解
2
思考 (Think)
LLM 基于记忆和输入进行推理，可能产生 thoughts、plans 或 self-critique
3
行动 (Act)
Agent 决定调用哪个工具或采取何种行动，可能是 API 调用、代码执行、数据库查询等
4
观察 (Observe)
Agent 观察行动的结果，更新内部状态，作为下一轮循环的输入
Agent 核心循环架构
关键点： Agent 的强大之处在于能够在单个任务中迭代多次循环。每次循环都利用前面的 observations 来改进决策，这是 Agent 相比 Chatbot 的本质优势。
Chatbot vs Agent 的对比
关键差异在于循环的深度和复杂性：
| 维度 |
简单 Chatbot |
AI Agent |
| 执行流程 |
单轮：输入 → LLM → 输出 |
多轮：感知 → 思考 → 行动 → 观察 → 反复 |
| 工具使用 |
通常不调用工具或仅推荐 |
主动调用 API/工具/代码 |
| 决策能力 |
由用户驱动 |
自主规划和决策 |
| 内存管理 |
单个对话轮次 |
跨轮次的持久内存 |
| 失败处理 |
无法恢复 |
可分析失败并重试 |
●●○○○○○○○○
ReAct 详解
Reasoning + Acting：最广泛使用的 Agent 模式
ReAct（Reasoning + Acting）是 2022 年 Yao et al. 提出的关键方法，在 HotpotQA、FEVER 等多个任务上超越了纯 CoT 和纯 Act 方法。核心思想是让 LLM 在每个步骤中显式地交替进行思考（Thought）和行动（Action），然后观察结果（Observation）。
ReAct 完整执行轨迹
问题: 2022 年哥伦比亚大学排名是多少？
Thought 1: 我需要搜索关于 2022 年哥伦比亚大学的排名信息。
Action 1: Search[2022年 哥伦比亚大学排名]
Observation 1: 2022年 US News 全国大学排名中，哥伦比亚大学排名第 3。
Thought 2: 我已经找到答案，但让我验证这是否是最准确的信息。
Action 2: Search[哥伦比亚大学 2022 QS排名]
Observation 2: QS 2022 排名中，哥伦比亚大学排名第 4。
Thought 3: 我现在有两个不同来源的信息。US News 排名第 3，QS 排名第 4。这是合理的，因为不同机构的排名方法不同。我可以给出答案了。
Action 3: Finish[2022年哥伦比亚大学在 US News 排名中位列第 3，在 QS 排名中位列第 4]
最终答案: 2022年哥伦比亚大学排名第 3（US News）/ 第 4（QS）
ReAct 的三个核心组成
Thought
思考
LLM 的内部推理过程，决定下一步的动作。可以包含子目标分解、假设验证等。
Action
行动
具体的工具调用或行动，格式为 Action: [tool_name][arguments]
Observation
观察
工具执行的结果或环境反馈，成为下一轮思考的输入
Finish
完成
特殊的 Action，表示 Agent 已得出最终答案，停止循环
ReAct vs CoT vs Act 性能对比
| 方法 |
HotpotQA |
FEVER |
特点 |
| Chain-of-Thought (CoT) |
66.3% |
86.5% |
只有思考，无法调用工具验证 |
| Act (纯行动) |
71.8% |
87.6% |
快速行动，但缺乏计划性 |
| ReAct (推荐) |
78.3% |
92.3% |
思考与行动结合，最优性能 |
ReAct Prompt 的关键设计
你是一个能够通过以下工具解答问题的助手：
工具列表:
- Search[query]: 搜索查询并返回相关文档
- Lookup[keyword]: 在当前页面中查找关键词
- Calculator[expression]: 计算数学表达式
使用以下格式回答问题:
问题: 你要回答的问题
Thought: 你应该始终思考你应该做什么
Action: 选择一个行动，格式为 Action: [工具名][参数]
Observation: 行动的结果
... (Thought/Action/Observation 可重复多次)
Thought: 我现在知道最终答案
Action: Finish[答案]
开始!
问题: {question}
面试考点
- ReAct 的关键创新是什么？ — 交替使用 Thought 和 Action，使推理和执行更加透明和可控
- 为什么 ReAct 比纯 CoT 更好？ — 可以通过实际工具调用来验证假设，而不是依赖 LLM 的想象
- 如何在 ReAct 中处理无限循环？ — 设置最大步数限制、检测重复状态、添加回溯机制
●●●○○○○○○○
Reflexion 与自我改进
通过自反思实现长期学习和持续改进
Reflexion 扩展了 ReAct 框架，在 Agent 失败时引入显式的自反思阶段。Agent 不仅观察结果，还主动评估错误原因、提取经验教训，并将其存储为长期记忆，用于指导未来的决策。
Reflexion 的完整循环
1
试验 (Trial)
Agent 执行 ReAct 循环尝试完成任务
2
评估 (Evaluate)
检查结果是否成功。可以通过 Ground Truth 比较、执行验证或人工反馈
3
反思 (Reflect)
如果失败，提示 LLM 分析失败原因，生成可迁移的经验（存入记忆）
4
重试 (Retry)
在之前反思的基础上重新尝试任务，直到成功
Reflexion 学习循环 vs 标准 ReAct
Reflexion 中的自反思提示
前置反思 (Pre-Reflection):
你之前尝试这个问题时失败了。以下是失败的轨迹和错误：
{failed_trajectory}
请反思：
1. 你的错误思路在哪里？
2. 哪个工具调用产生了意外结果？
3. 你应该采取什么不同的策略？
重要：用一句话总结这次失败的经验教训。
实验结果： 在 HumanEval 编程任务上，Reflexion 将 ReAct 的成功率从 80% 提升到 91%。类似的改进也在代码调试、数学推理等任务上被观察到。
LATS：蒙特卡洛树搜索的 Agent 版本
进一步的改进方向是使用 Language Agent Tree Search (LATS)，结合蒙特卡洛树搜索 (MCTS) 和 Reflexion，在探索-利用之间更好地平衡：
Selection
选择
使用 UCB 算法选择最有前景的行动序列
Simulation
模拟
执行行动序列到完成或失败
Backpropagation
反向传播
更新树中的行动价值，指导未来的选择
●●●●○○○○○○
记忆系统设计
三层架构：短期、工作、长期记忆
高效的记忆系统是 Agent 超越单轮对话的关键。Agent 需要在多个时间尺度上管理信息：实时的上下文窗口（短期）、当前任务的工作簿（工作）、以及跨任务的持久学习（长期）。
三层记忆架构
Agent 记忆系统三层架构
MemGPT：虚拟上下文管理
当任务超过 LLM 上下文窗口时，MemGPT 引入了虚拟内存的概念：将长期数据存储在向量 DB 中，Agent 通过显式的 read_memory 和 write_memory 工具来管理。这使得 Agent 能够处理无限长的对话和任务。
| 记忆类型 |
容量 |
延迟 |
更新频率 |
使用场景 |
| 短期 |
2K-200K tokens |
~0ms |
每步 |
当前推理 |
| 工作 |
任意大小（有开销） |
~1-10ms |
每次思考 |
任务规划和中间结果 |
| 长期 |
无限 |
~100-500ms |
每个任务 |
跨任务的持久知识 |
检索评分公式
score = α × recency + β × relevance + γ × importance
面试考点
- 如何处理超长的对话历史？ — 使用检索增强的长期记忆而不是完整回放
- 记忆中的冗余如何解决？ — 定期去重、相似性合并、优先级淘汰
- 短期和长期记忆的权衡？ — 短期用于准确性，长期用于可扩展性
●●●●●○○○○○
工具调用实现
从 OpenAI Functions 到 Anthropic Tool Use 的演进
工具调用是 Agent 与环境交互的关键接口。现代 LLM 已从文本生成工具调用演进到原生支持结构化输出。我们对比两种主流方案。
OpenAI Function Calling
// 步骤 1: 定义可用的函数
const functions = [
{
name: "search",
description: "在互联网上搜索信息",
parameters: {
type: "object",
properties: {
query: { type: "string", description: "搜索查询" }
},
required: ["query"]
}
},
{
name: "calculator",
description: "进行数学计算",
parameters: {
type: "object",
properties: {
expression: { type: "string", description: "数学表达式" }
},
required: ["expression"]
}
}
];
// 步骤 2: 调用 API
const response = await openai.createChatCompletion({
model: "gpt-4",
messages: [{ role: "user", content: "2022年哥伦比亚大学排名?" }],
functions: functions,
function_call: "auto"
});
// 步骤 3: 检查是否请求了函数调用
if (response.choices[0].message.function_call) {
const funcName = response.choices[0].message.function_call.name;
const funcArgs = JSON.parse(response.choices[0].message.function_call.arguments);
const result = await executeFunction(funcName, funcArgs);
// 步骤 4: 将结果返回给模型
const followUpResponse = await openai.createChatCompletion({
model: "gpt-4",
messages: [
{ role: "user", content: "..." },
{ role: "assistant", content: "", function_call: {...} },
{ role: "function", name: funcName, content: JSON.stringify(result) }
]
});
}
Anthropic Tool Use
// 定义工具（使用 JSON Schema）
const tools = [
{
name: "search",
description: "搜索互联网信息",
input_schema: {
type: "object",
properties: {
query: { type: "string" }
},
required: ["query"]
}
}
];
// 调用 Claude 并启用工具使用
const response = await client.messages.create({
model: "claude-3-5-sonnet-20241022",
max_tokens: 4096,
tools: tools,
messages: [
{ role: "user", content: "2022年哥伦比亚大学排名?" }
]
});
// 处理工具调用
if (response.stop_reason === "tool_use") {
for (const block of response.content) {
if (block.type === "tool_use") {
const toolName = block.name;
const toolInput = block.input;
const toolResult = await executeFunction(toolName, toolInput);
// 将结果继续对话
const continueResponse = await client.messages.create({
model: "claude-3-5-sonnet-20241022",
max_tokens: 4096,
tools: tools,
messages: [
{ role: "user", content: "..." },
{ role: "assistant", content: response.content },
{
role: "user",
content: [
{
type: "tool_result",
tool_use_id: block.id,
content: JSON.stringify(toolResult)
}
]
}
]
});
}
}
}
错误处理和重试策略
1
验证工具调用的有效性
检查返回的 JSON 是否能被解析，参数是否符合 schema
2
执行工具并捕获异常
如果工具执行失败（如网络错误、超时），返回清晰的错误信息
3
重试或回滚
对于幂等工具可自动重试，否则提示用户或选择备选方案
4
记录异常到长期记忆
学习哪些工具调用容易失败，便于未来避免
常见陷阱： LLM 有时会幻想工具不存在的参数或调用不存在的函数。通过将 tool schema 清晰地放入 system prompt 并提供失败示例来减少幻觉。
并行工具调用
现代 LLM 支持在一个响应中生成多个工具调用，提高效率。关键是正确处理这些并行工具的结果聚合。
| 方面 |
OpenAI Functions |
Anthropic Tool Use |
| 定义方式 |
JSON Schema + 可选描述 |
JSON Schema + 必需描述 |
| 响应格式 |
function_call 对象 |
content 数组中的 tool_use 块 |
| 并行调用 |
最近版本支持 |
原生支持 |
| 错误处理 |
需自己实现 |
通过 tool_result 反馈 |
●●●●●●○○○○
编排模式详解
六种常见的多 Agent 架构模式
当系统需要多个 Agent 协作时，编排模式决定了它们如何通信、决策和执行。我们讨论六种主要模式，从简单到复杂。
1. Single Agent（单 Agent）
Single Agent 架构
// 最简单的实现
while !done:
observation = observe_environment()
thought = llm.think(observation, memory)
action = llm.decide_action(thought)
result = execute(action)
update_memory(thought, action, result)
2. Router（路由器）
将任务根据内容分类到不同的专家 Agent。
Router 模式
def route_and_execute(query):
category = classifier_llm(query) # 将查询分类
if category == "coding":
agent = coding_specialist
elif category == "math":
agent = math_specialist
else:
agent = knowledge_specialist
result = agent.execute(query)
return result
3. Orchestrator-Worker（协调器-执行者）
一个规划 Agent 分解任务，多个执行 Agent 并行执行子任务。
Orchestrator-Worker 模式
def orchestrator_worker_pattern(task):
# 步骤 1: 规划
subtasks = orchestrator_llm.decompose(task)
# 步骤 2: 分配和执行（可以并行）
results = []
for subtask in subtasks:
result = worker_agent.execute(subtask)
results.append(result)
# 步骤 3: 聚合
final_result = orchestrator_llm.aggregate(results, task)
return final_result
4. Pipeline（管道）
一个 Agent 的输出是下一个 Agent 的输入，形成处理链。
5. Hierarchical（分层）
树形结构，高层 Agent 做决策，低层 Agent 做执行，支持递归分解。
6. Evaluator-Optimizer（评估-优化）
一个 Agent 生成候选方案，另一个 Agent 评估并反馈改进方向，迭代优化。
Evaluator-Optimizer 模式
●●●●●●●○○○
框架对比实战
LangGraph, CrewAI, AutoGen, OpenAI Agents, Claude Code 对比
选择合适的框架对 Agent 开发效率至关重要。下表对五个主流框架进行了详细对比。
| 框架 |
核心特点 |
适用场景 |
学习曲线 |
| LangGraph |
有状态图、Checkpointing、Human-in-Loop |
复杂工作流、需要保存状态的应用 |
中等 |
| CrewAI |
基于角色的简化框架、快速原型 |
演示、快速迭代、教学 |
低 |
| AutoGen |
多 Agent 对话、代码执行、自动化 |
需要代码执行的任务、智能协作 |
中等 |
| OpenAI Agents |
原生集成 GPT、Handoffs、Guardrails |
OpenAI 生态的应用 |
低到中 |
| Claude Code |
MCP 协议、终端执行、Anthropic 优化 |
工程任务、系统操作、本地执行 |
中到高 |
LangGraph 示例
from langgraph.graph import StateGraph
from typing import TypedDict
class AgentState(TypedDict):
messages: list
current_step: int
def create_agent_graph():
graph = StateGraph(AgentState)
# 定义节点
graph.add_node("think", think_node)
graph.add_node("act", act_node)
graph.add_node("observe", observe_node)
# 定义边
graph.add_edge("think", "act")
graph.add_conditional_edges("act", decide_next_step)
# 编译成可执行图
return graph.compile(checkpointer=memory_saver)
CrewAI 示例
from crewai import Agent, Task, Crew
# 定义 Agent（基于角色）
researcher = Agent(
role="研究员",
goal="进行深入研究并提供见解",
tools=[search_tool, web_scraper],
llm=claude
)
analyst = Agent(
role="分析师",
goal="分析研究结果并生成报告",
tools=[analysis_tool],
llm=claude
)
# 定义任务
research_task = Task(
description="研究 AI Agent 的最新进展",
agent=researcher
)
analysis_task = Task(
description="分析研究结果",
agent=analyst,
depends_on=[research_task]
)
# 组成 Crew
crew = Crew(agents=[researcher, analyst], tasks=[research_task, analysis_task])
result = crew.kickoff()
AutoGen 示例
import autogen
# 定义 Agent
user_proxy = autogen.UserProxyAgent(
name="user_proxy",
human_input_mode="TERMINATE"
)
coder = autogen.AssistantAgent(
name="coder",
llm_config={"model": "gpt-4", "api_key": api_key}
)
# 启用代码执行
user_proxy.initiate_chat(
coder,
message="编写 Python 代码计算斐波那契数列的前 10 项"
)
# AutoGen 会自动进行对话和代码执行
OpenAI Agents 示例
from openai import Client
client = Client(api_key="...")
# 创建 Agent（带 Handoffs）
agent = client.agents.create(
model="gpt-4",
name="支持 Agent",
instructions="你是一个客户支持助手。如果用户问题涉及技术问题，转接给技术团队。",
tools=[search_tool, ticket_tool]
)
# Handoff 到另一个 Agent
transfer_tool = {
"type": "function",
"function": {
"name": "transfer_to_technical",
"description": "转接给技术支持团队"
}
}
Claude Code / MCP 示例
// 在 Claude Code 中通过 MCP 执行本地操作
import { spawn } from 'child_process';
// MCP 工具定义
const tools = [
{
name: "run_command",
description: "在本地终端中运行 Shell 命令",
input_schema: {
type: "object",
properties: {
command: { type: "string" }
}
}
},
{
name: "read_file",
description: "读取本地文件内容",
input_schema: {
type: "object",
properties: {
path: { type: "string" }
}
}
}
];
// 通过 MCP 调用本地工具
const result = await mcp.call_tool("run_command", {
command: "npm test --watch"
});
面试考点
- 为什么选择 LangGraph 而不是 CrewAI？ — LangGraph 提供更细粒度的控制和 Checkpointing，适合生产级应用
- AutoGen 的代码执行如何保证安全？ — 通过沙箱执行和代码审查的两层防护
- OpenAI Agents 的 Handoffs 如何实现？ — 通过特殊的工具调用触发 Agent 转接
●●●●●●●●○○
MCP 与 A2A 协议
Agent 通信标准与工具集成
MCP（Model Context Protocol）是 Anthropic 提出的开放标准，为 LLM 应用定义了统一的工具、资源和提示集成接口。A2A 是一个更广泛的 Agent-to-Agent 通信协议。
MCP 架构
MCP 系统架构
MCP 的三个核心组件
Tools
工具
供 LLM 调用的函数/API，带有 JSON Schema 定义
Resources
资源
供 LLM 访问的数据/文件，支持列表和读取操作
Prompts
提示
预定义的 system prompt 模板，可参数化
Transport
传输
stdio（进程通信）或 SSE（HTTP 流）
A2A 协议概述
Agent-to-Agent (A2A) 协议是一个更广泛的框架，用于多个 Agent 之间的通信和协作：
| 维度 |
MCP |
A2A |
| 主要目的 |
LLM ↔ 工具/资源的集成 |
Agent ↔ Agent 的协作 |
| 通信模式 |
请求-响应（JSON-RPC） |
消息队列、Event-driven |
| 关键元素 |
Tools、Resources、Prompts |
Agent Card、Task、Capabilities |
| 标准化程度 |
更成熟（Anthropic 官方） |
正在演进中 |
MCP 的优势： 通过定义统一的接口，MCP 使得不同的 LLM 应用能够复用相同的工具和资源集成。这加速了生态繁荣，避免了重复开发。
●●●●●●●●●○
评估与可靠性
基准测试、可靠性工程与成本优化
评估 Agent 的性能和可靠性不能只看准确性。我们需要综合考虑任务完成度、效率、成本和安全性。
主流 Agent 评估基准
| 基准 |
任务类型 |
主要指标 |
难度 |
| SWE-bench |
软件工程（PR 解决） |
成功率、时间成本 |
极难 |
| WebArena |
Web 交互（购票、预订等） |
任务完成率、精准度 |
很难 |
| GAIA |
多步推理（复杂问题） |
答案准确性 |
难 |
| HotpotQA |
多跳问答 |
F1 分数、准确率 |
中 |
评估的四个维度
1
任务完成度
Agent 是否成功完成了用户的目标任务？使用 Exact Match、F1、BLEU 等指标
2
效率指标
完成任务所需的步骤数、Token 消耗、执行时间。更少更好。
3
安全性评估
是否有恶意输入被正确拒绝？是否遵守权限边界？
4
成本分析
API 调用成本、基础设施成本、维护成本的总和
可靠性工程实践
class ReliableAgent:
def __init__(self, max_retries=3, timeout=30):
self.max_retries = max_retries
self.timeout = timeout
def execute_with_fallback(self, action):
"""执行带重试和回滚的行动"""
for attempt in range(self.max_retries):
try:
result = self.execute(action, timeout=self.timeout)
return result
except ToolError as e:
if attempt == self.max_retries - 1:
return self.fallback_action(action, error=e)
self.log_error(e)
def fallback_action(self, action, error):
"""定义降级方案"""
if action.tool == "search":
# 如果搜索失败，使用知识库
return self.knowledge_base.query(action.args)
elif action.tool == "api_call":
# 如果 API 超时，返回缓存结果
return self.cache.get(action.args)
def monitor_performance(self, metrics):
"""监控关键指标"""
if metrics['error_rate'] > 0.1:
self.alert("Error rate too high!")
if metrics['avg_latency'] > 5000:
self.alert("Performance degradation!")
成本优化策略
| 优化方向 |
具体方法 |
预期节省 |
| 模型选择 |
用更小的模型（如 Haiku）处理简单任务 |
50-80% |
| Token 优化 |
精简提示词、使用摘要而非完整文档 |
20-40% |
| 缓存策略 |
缓存常见查询和结果 |
30-60% |
| 工具选择 |
优先使用便宜的 API（如 BM25 搜索） |
40-70% |
面试考点
- 如何评估 Agent 的可靠性？ — 使用成功率、平均步数、错误分析等多维度评估
- 如何在精准性和成本之间平衡？ — 分层处理，复杂查询用强模型，简单任务用弱模型
- 面对生产故障的应急方案？ — 多重重试、降级、人工接入三层防护
HARNESS
Agent Harness 运行时架构
模型是引擎，Harness 是汽车 — 没有转向和刹车的引擎毫无用处
Agent Harness 是包裹在 LLM 之外的运行时基础设施，负责 orchestration loop、tool routing、memory management、guardrails 和 error recovery。与直接调用 LLM API 不同，Harness 将「裸模型」转变为一个可靠的、可控的 Agent 系统。2025 年被称为 Agent 年，而 2026 年正在成为 Harness 年 — 因为模型能力逐渐趋同，真正的竞争壁垒在于 Harness 工程。
Harness vs Framework vs Runtime
Framework（如 LangChain）关注 agentic logic — Agent 做什么；Runtime（如 LangGraph）关注状态管理和持久化；Harness 关注生产运行的完整基础设施 — orchestration、durability、safety、observability 的全栈集成。
核心组件架构
Agent Harness 六层架构
各层详解
① Context Engineering — 构建最优上下文
Context Engineering 是 Harness 中最被低估的核心能力。它解决的问题是：在有限的 token 窗口内，如何组装出最有助于 Agent 正确决策的上下文？
A
Dynamic System Prompt
按优先级条件加载 prompt 片段。例如：只有当用户提到代码时才注入 coding guidelines；只有当检测到安全敏感操作时才注入 safety rules。避免一次性塞入所有指令导致注意力分散。
B
Event-Driven Reminders
在 Agent 执行过程中的关键决策点注入针对性的行为引导。例如：当连续失败 3 次时注入 "请考虑更换策略"；当 token 消耗超过 80% 时注入 "请精简输出"。
C
Adaptive Context Compaction
渐进式压缩较旧的对话轮次。使用熵减原则 — 保留信息密度最高的部分，压缩重复或冗余内容。确保长任务不会因 context overflow 而失败。
② Orchestration Loop — 六阶段执行引擎
Harness 的核心是一个增强版 ReAct 循环。每次迭代经历六个阶段：
def agent_loop(task):
# 六阶段执行循环
while not task.is_complete():
# Phase 1: Pre-check — 上下文压缩、权限验证
context = compact_and_validate(task.context)
# Phase 2: Think — LLM 推理当前状态
thought = llm.reason(context, task.goal)
# Phase 3: Self-Critique — 检查推理质量
if thought.confidence < threshold:
thought = llm.refine(thought, critique_prompt)
# Phase 4: Plan — 选择下一步行动
action = llm.plan_action(thought, available_tools)
# Phase 5: Execute — 通过 Tool Registry 执行
result = tool_registry.execute(action, permissions)
# Phase 6: Post-process — 更新状态、记录轨迹
task.update(result)
trace_logger.record(thought, action, result)
③ Tool Registry — 统一工具管理
Tool Registry 是 Harness 管理所有外部工具的核心组件。它负责工具的注册、发现、权限控制和调用：
| 能力 |
实现方式 |
示例 |
| 懒发现 |
通过 MCP 协议动态发现可用工具 |
Agent 启动时不加载所有工具，按需从 MCP Server 获取 |
| 权限边界 |
Allowlist/Denylist + 分层权限 |
文件工具只能访问 /workspace 目录，不能访问 /etc |
| 自动重试 |
Exponential backoff + 降级策略 |
API 超时 → 重试 3 次 → 返回缓存结果 |
| 并行执行 |
无依赖的工具调用可并行 |
同时搜索 3 个数据源，合并结果 |
④ Memory & State — 双轨记忆架构
高质量 Harness 使用双轨记忆分离 episodic memory（历史观察）和 working memory（当前迭代状态）：
Episodic Memory
长期经验
历史观察、Reflexion 结果、跨 Session 的学习经验。存储在向量 DB 或文件系统中。通过 retrieval 按相关性召回。
Working Memory
当前任务状态
当前迭代的 scratchpad、中间计算结果、已执行的步骤记录。存储在内存中，随 task 结束释放。支持 checkpoint 和 rollback。
Session Persistence
跨会话连续性
Context 压缩、overflow 恢复、摘要续接。确保长任务即使中断也能恢复执行。使用 checkpoint 机制保存执行快照。
Strategy Storage
策略持久化
成功的问题解决策略（Playbooks）持久化存储。下次遇到相似问题时直接复用策略，减少探索成本。
⑤ Guardrails — 五层独立防御
生产级 Harness 需要五层独立的安全防御，每一层独立运行，即使其他层失效也能提供保护：
L1
Permission Boundaries — 权限边界
定义 Agent 可以访问的资源范围。包括：文件系统路径白名单、网络访问 ACL、API 调用频率限制、敏感数据访问控制。
L2
Validation Checks — 输出验证
在 Agent 输出被实际应用之前进行验证。代码类任务：Linter + Type Checker + Test Suite；数据类任务：Schema 验证 + 范围检查。
L3
Architectural Constraints — 架构约束
强制执行系统架构规则。例如：Agent 不能修改 config 文件、不能直接写入数据库主表、不能跳过 staging 直接操作 production。
L4
Doom Loop Detection — 死循环检测
检测并中止循环执行模式。包括：重复状态检测（相同 observation hash）、步数上限（max_iterations）、Token 消耗上限、重复 action 序列检测。
L5
Human Approval Gating — 人工审批
高风险操作（如删除文件、发送邮件、修改 production）需要人工确认。Harness 暂停执行，等待人工批准后继续。
主流 Harness 框架对比 (2025)
| 框架 |
设计哲学 |
核心特性 |
适用场景 |
| Anthropic Claude Agent SDK |
Tool-use-first，极简抽象 |
Agent = Claude + Tools；Sub-agent 可作为 Tool；开发者显式控制 Agent Loop |
需要精细控制的生产 Agent |
| OpenAI Agents SDK |
轻量多 Agent 协调 |
智能 Handoff（Triage → Specialist）；支持 100+ LLM；内置 Session 和 Tracing |
多 Agent 路由与协作 |
| LangGraph |
图编排 + 状态持久化 |
Checkpoint 恢复；Time-Travel Debug；Human-in-Loop；独立于 LangChain 核心 |
复杂有状态工作流 |
| CrewAI 2.0 |
角色化多 Agent |
60% Fortune 500 采用；集成 Gmail/Slack/Notion 等；顺序或并行任务 |
企业级多 Agent 快速部署 |
| Inngest / Temporal |
通用 Workflow 引擎 |
Durable Execution；每步独立重试；Serverless 编排 |
需要强容错的生产系统 |
Harness 架构模式
Event-Driven 架构
现代 Harness 采用事件驱动架构：Webhook（Telegram/Slack）或 WebSocket 触发 typed events → Persistent Worker 处理 → 每个 LLM 调用和工具执行成为独立可重试的 step。这使得整个 think→act→observe 循环具备容错性和可观测性。
// Inngest-style Step-Based Execution
const agentTask = inngest.createFunction(
{ id: "agent-task" },
{ event: "agent/task.received" },
async ({ event, step }) => {
// 每个 step 独立可重试
const plan = await step.run("think", () =>
llm.reason(event.data.context)
);
const result = await step.run("execute", () =>
toolRegistry.dispatch(plan.action)
);
// 递归：如果未完成，触发下一轮
if (!result.done) {
await step.invoke("next-iteration", {
function: agentTask,
data: { ...event.data, context: result.newContext }
});
}
}
);
Sub-Agent 委派模式
Harness 可以 spawn 隔离的 sub-agent 实例，每个 sub-agent 拥有：独立的 context window、过滤后的 tool 子集、有限的执行范围。这实现了并行探索和任务分解：
Main Agent → spawn(SubAgent1[tools: {search, read}]) ‖ spawn(SubAgent2[tools: {code, test}])
Harness 工程五大支柱
Pillar 1
Tool Orchestration
定义访问边界、调用模式和能力约束。包括 MCP 集成、工具发现、权限管理。
Pillar 2
Guardrails
确定性规则防止有害操作。五层独立防御，每层独立运行。
Pillar 3
Error Recovery
优雅的失败处理：自动重试、自我验证、checkpoint 回滚、降级方案。
Pillar 4
Observability
完整的执行可视化：Trace Logging、Token Tracking、Decision Recording、Anomaly Detection。
Pillar 5
Human-in-the-Loop Checkpoints
在高杠杆决策点引入人工判断。不是所有操作都需要审批，而是在关键分支处设置检查点 — 如修改生产环境、发送外部通信、执行不可逆操作时暂停等待人工确认。
面试考点
- Agent Harness 和 Agent Framework 的区别是什么？ — Framework 关注 agentic logic（做什么），Harness 关注生产基础设施（如何可靠地做）。Harness 包含 orchestration、durability、safety、observability 全栈。
- 为什么说 2026 是 Harness 年？ — 模型能力趋同（Claude/GPT/Gemini 差距缩小），真正的竞争壁垒转向 Harness 工程。世界级团队在 Harness 上投入 6-12 个月的迭代改进。
- 如何设计 Context Engineering？ — Dynamic System Prompt（按条件加载）、Event-Driven Reminders（在决策点注入引导）、Adaptive Compaction（熵减原则压缩历史）、Token Budgeting（预算管理）。
- Doom Loop Detection 如何实现？ — 四重检测：重复 observation hash、步数上限、Token 上限、重复 action 序列。任一触发即中止循环。
EVAL
Evaluation Harness 与 Agent 评估
标准化基准 · 沙箱隔离 · 可靠性度量 — 如何科学地衡量 Agent 能力
Evaluation Harness 是用于系统化基准测试和评估 AI Agent 的基础设施。与 Runtime Harness（执行 Agent）不同，Evaluation Harness 测量 Agent 的能力、可靠性和安全合规性。它需要解决三个核心问题：可复现的执行环境（容器化沙箱）、标准化的评估协议（任务定义 + 评分规则）、以及有意义的度量指标。
主流评估框架
Inspect AI (UK AISI)
英国 AI 安全研究所（AISI）开发的开源 Python 框架，已成为 Agent 评估的事实标准。其核心架构遵循 Dataset → Task → Solver → Scorer 的 pipeline：
# Inspect AI 评估示例
from inspect_ai import Task, task, eval
from inspect_ai.dataset import json_dataset
from inspect_ai.solver import generate, use_tools
from inspect_ai.scorer import match
@task
def agent_eval():
return Task(
dataset=json_dataset("tasks.json"),
solver=[use_tools(), generate()], # Agent 使用工具后生成答案
scorer=match(), # 精确匹配评分
sandbox="docker", # Docker 沙箱隔离
)
# 运行评估
eval(agent_eval(), model="anthropic/claude-sonnet-4-6")
Sandbox Plugins
三级隔离
Docker Compose：多容器场景；Kubernetes：复杂扩展环境；Proxmox：高风险评估的强 VM 隔离。三轴控制：Tooling / Host / Network。
Adoption
50+ 贡献者
来自多个 AI 安全研究所、前沿实验室和研究机构。支持 GAIA、SWE-Bench、Cybench 等主流基准。
核心基准测试对比
| 基准 |
领域 |
任务规模 |
评估方式 |
SoTA (2025) |
人类基线 |
| SWE-bench Verified |
软件工程 |
500 issues |
Docker 容器化执行 |
~75% |
专家筛选 |
| WebArena |
Web 自动化 |
812 tasks |
功能状态验证 |
61.7% |
78.2% |
| OSWorld |
桌面控制 |
369 tasks |
真实 OS 执行 |
12.2% |
72.4% |
| GAIA |
通用推理 |
450 Q&A |
多模态多步骤 |
— |
— |
| TAU-bench |
工具对话 |
多行业 |
终态对比 |
25% (pass^88) |
— |
各基准详解
SWE-bench — 软件工程能力评估
SWE-bench 从真实 GitHub issue 出发，给定代码库和问题描述，Agent 必须生成修复 patch。SWE-bench Verified 是经过 93 名专业开发者筛选的高质量子集（500 issues），过滤了过于特定的测试、描述不清的 issue 和复杂的环境配置问题。
2024 年 6 月全面迁移至 Docker 容器化评估，确保可复现性。性能从 2024 初的 ~20% 飙升至 2025 年的 ~75%。变体包括 SWE-bench Multimodal（ICLR 2025）和 Auto-SWE-Bench（自动生成）。
WebArena — Web 交互评估
模拟真实网站环境，涵盖电商、社交论坛、协作开发和 CMS 四个领域的 812 个长 horizon 任务。评估方式是功能性终态验证 — 只看 Agent 的操作是否让环境达到了满足用户意图的状态，不关心具体路径。
从 GPT-4 最初的 14.4% 到 2025 年 IBM CUGA 的 61.7%，但仍低于人类的 78.2%。更难的 WebChoreArena 变体 SoTA 仅 37.8%。
OSWorld — 桌面操控评估
NeurIPS 2024 提出的首个真实操作系统环境基准。在 Ubuntu Linux 和 Windows 上执行 369 个任务，涵盖 OS 文件 I/O、Web 交互、多应用工作流和桌面 GUI 操作。
人类完成率 72.4%，而最佳模型仅 12.2% — 差距最大的基准，揭示了 GUI grounding 和操作知识的巨大瓶颈。2025 年推出 OSWorld-Verified 版本，通过 AWS 并行化将评估时间缩短至约 1 小时。
TAU-bench — 工具使用可靠性评估
TAU-bench 的独特价值在于引入了可靠性度量。它模拟 User（LLM 扮演）和 Agent 之间的多轮对话，Agent 需要使用领域特定 API 工具并遵循 policy guidelines。评估仅看最终数据库状态是否匹配目标。
pass@k vs pass^k — 可靠性的关键区别
pass@k：k 次独立试验中至少成功一次的概率 → 衡量 Agent 能不能做到
pass^k：k 次独立试验中全部成功的概率 → 衡量 Agent 能不能稳定做到
GPT-4o 在零售领域单次成功率 61%，但 pass^88 可靠性低于 25%。这揭示了一个关键事实：单次成功 ≠ 生产可靠。
评估方法论演进
T1
终态验证优于轨迹评估
现代评估关注最终状态是否正确，而非逐步检查。接受多样化的解题路径，只要目标达成即可。实现方式：数据库状态对比、功能性输出验证、自动化校验器。
T2
可靠性优先于成功率
2025 年的基准越来越重视 pass^k 而非 pass@k。一个 Agent 单次能完成 70% 的任务但每次结果不一样，不如一个稳定完成 50% 任务的 Agent 适合生产。
T3
从模拟到真实环境
评估环境逐步从模拟走向真实：text-only → simulated web → real OS（OSWorld）。更真实的环境暴露出更多 Agent 能力的瓶颈，尤其是 GUI grounding。
T4
Policy-Aware 评估
TAU-bench 开创了将 policy compliance 纳入评估的先例。Agent 不仅要完成任务，还要遵守业务规则（如退货政策、优惠券限制）。这对生产部署至关重要。
沙箱化评估架构
可靠的评估需要严格的沙箱隔离，Inspect AI 定义了三个隔离轴：
| 隔离轴 |
控制内容 |
实现方式 |
| Tooling |
Agent 可访问的工具和代码执行能力 |
工具白名单、沙箱内代码执行、API mock |
| Host |
防止 Agent 逃逸宿主系统 |
Docker/Kubernetes 容器隔离、Proxmox VM 隔离 |
| Network |
控制 Agent 的外部网络访问 |
网络策略、DNS 过滤、出站流量监控 |
面试考点
- pass@k 和 pass^k 的区别？为什么 pass^k 更重要？ — pass@k 衡量能不能做到（至少一次成功），pass^k 衡量能不能稳定做到（每次都成功）。生产环境需要可靠性，不是运气。GPT-4o 零售单次 61% 但 pass^88 低于 25%。
- 为什么 OSWorld 比 WebArena 难得多？ — OSWorld 需要 GUI grounding（从像素理解 UI 元素位置）和操作系统知识，而 WebArena 在结构化 DOM 上操作。人类-模型差距：OSWorld 60pp vs WebArena 16pp。
- SWE-bench 性能飙升的原因？ — 更好的 Agent harness（tool use + planning）、更长的 context window、Docker 容器化带来的环境一致性、以及 Agentic coding 范式（如 Devin、Cursor Agent）的成熟。
- 如何设计 Agent 评估的沙箱？ — 三轴隔离：Tooling（工具白名单）、Host（容器/VM 隔离）、Network（出站控制）。用 Docker Compose 做多容器场景，Proxmox 做高风险评估。
●●●●●●●●●●
面试题库
精选 15 道 Agent 工程的核心面试题
Q1
请解释 Agent 与 Chatbot 的核心区别。
答案要点：(1) Agent 能进行多步规划和自主决策，Chatbot 是被动响应；(2) Agent 有工具调用能力，Chatbot 仅生成文本；(3) Agent 维护持久记忆，Chatbot 通常无状态；(4) Agent 能从失败中反思和学习。
Q2
ReAct 框架的核心思想和与 CoT 的关键差异是什么？
答案要点：ReAct 交替进行 Thought 和 Action，在实际执行工具后验证假设，而 CoT 只进行思考而不实际验证。性能：在 HotpotQA 上 ReAct 78.3% vs CoT 66.3%。
Q3
在 ReAct 中，如何避免 Agent 陷入无限循环？
答案要点：(1) 设置最大步数限制；(2) 检测重复状态（相同的观察）；(3) 实现回溯机制（保存检查点，允许回退）；(4) 在 Thought 中显式告诉 Agent 当前已执行的步数。
Q4
Reflexion 是如何改进 ReAct 的？请给出一个改进的具体例子。
答案要点：Reflexion 在失败后引入反思阶段，提取可迁移的经验存入长期记忆。例子：第一次尝试用错误的 API，失败后反思「这个 API 返回的字段名是 title 而不是 name」，存入记忆，下次使用时直接用正确字段名。HumanEval 性能 80% → 91%。
Q5
描述 Agent 的三层记忆系统，以及它们如何协作。
答案要点：短期（上下文窗口，2K-200K tokens，每步更新）→ 工作（scratchpad，临时计算）→ 长期（向量 DB，跨任务学习）。协作：短期用于当前推理，工作支持任务规划，长期提供历史知识。
Q6
如何设计 Agent 长期记忆的检索评分函数？
答案要点：score = α × recency + β × relevance + γ × importance。recency = 1/(1+days_ago)，relevance 用向量相似度，importance 由用户评分或 Agent 自动标记。三个系数可根据场景调整。
Q7
OpenAI Function Calling 和 Anthropic Tool Use 的主要区别？
答案要点：定义方式（OAI: JSON Schema; Anthropic: 必需描述）、响应格式（OAI: function_call; Anthropic: tool_use block）、并行支持（Anthropic 原生支持）、错误处理（Anthropic 通过 tool_result 反馈）。
Q8
请比较 Router、Orchestrator-Worker 和 Hierarchical 三种编排模式。
答案要点：Router 用分类器路由任务，适合任务类别明确的场景；Orchestrator-Worker 规划者分解任务再分配，适合复杂任务；Hierarchical 树形递归分解，适合嵌套任务。性能依次递增但复杂度也增加。
Q9
为什么选择 LangGraph 而不是 CrewAI？列举 3 个关键原因。
答案要点：(1) LangGraph 提供 Checkpointing，支持状态持久化和恢复；(2) Human-in-Loop 支持更细粒度的控制；(3) 复杂工作流的定制能力更强。CrewAI 适合快速原型，LangGraph 适合生产级应用。
Q10
MCP 协议的核心优势是什么？它如何推动 Agent 生态发展？
答案要点：MCP 定义了统一的 Tools、Resources、Prompts 接口。优势：(1) 不同 LLM 应用可复用相同工具集；(2) 降低集成成本；(3) 加速工具生态繁荣；(4) 标准化促进互操作性。
Q11
如何在 Agent 中实现可靠性？给出一个具体的容错机制。
答案要点：(1) 重试机制：失败 3 次后降级；(2) 超时保护：30s 无结果则失败；(3) 缓存：常见查询返回缓存结果；(4) 降级方案：搜索失败则用知识库。代码示例见可靠性工程部分。
Q12
设计一个 Agent 评估系统，需要监控哪些关键指标？
答案要点：(1) 任务完成率（Task Success Rate）；(2) 平均步数（Avg Steps）；(3) Token 消耗（Token Usage）；(4) 平均延迟（Avg Latency）；(5) 错误率和错误类型分布；(6) 成本效率（Cost per Task）；(7) 安全事件数。
Q13
如何优化 Agent 的成本？给出一个量化的优化方案。
答案要点：分层处理（简单用 Haiku 50% 便宜，复杂用 Sonnet）、Token 优化（减少提示词冗余 20-40%）、缓存常见查询（节省 30-60%）、使用便宜 API（BM25 vs LLM 搜索节省 40-70%）。综合可降低 50% 以上。
Q14
在多 Agent 系统中，如何处理 Agent 之间的冲突和协调？
答案要点：(1) 显式的协议定义（谁决策、谁执行）；(2) 中央协调者（Orchestrator）;(3) 优先级机制；(4) 投票或共识算法；(5) 冲突解决规则预先定义；(6) 审计日志记录所有决策。
Q15
请设计一个完整的 Agent 系统用于「自动化代码审查」。包括架构、工具、评估指标。
答案要点：架构：Orchestrator（分解代码块和审查维度） → 多个 Specialist Agents（Security、Performance、Style 等） → Aggregator（汇总意见）。工具：静态分析、测试执行、向量搜索（相似代码）。指标：发现的 bug 数、误报率、审查速度。