Agent Foundations 面试 Cheat Sheet

§0 TL;DR Cheat Sheet

1. Agent = LLM policy + tool I/O + memory + control loop。最小骨架（ReAct, Yao et al. 2022, arXiv:2210.03629, ICLR 2023）：循环 Thought → Action → Observation → Thought … 直到生成 Finish[answer]。Action 调外部工具（search / calculator / shell），observation 反喂 context，scratchpad 在每轮拼回 prompt。
2. 比起 vanilla CoT 的关键收益：CoT 只在 latent space 里"想"，hallucination 会一路传播；ReAct 让模型在每一步可以离开自己脑子去查证（Wikipedia API、Python interpreter、code execution）→ 在 ALFWorld / WebShop 等 interactive decision 任务上比 IL/RL baseline 绝对成功率高 34% / 10%（仅 1-2 个 in-context examples）。但纯 ReAct 在 HotpotQA EM 上 (27.4) 反而低于纯 CoT (29.4) 和 CoT-SC (33.4)；真正最强的是 ReAct ↔ CoT-SC 互补 fallback (HotpotQA 35.1, Fever 64.6)。
3. Plan-and-Execute / Plan-and-Solve (Wang et al. 2023, ACL, arXiv:2305.04091)：先 plan（"Let's first understand the problem and devise a plan… Then carry out the plan step by step."），再逐步 execute。优势是 horizon 长时不会"走着走着忘了目标"；缺点是 plan 错就一路错（缺乏 replan 机制时）。生产里通常 hybrid：Plan-and-Execute 起手 + ReAct 每步 fall-back。
4. Tool use 的三大范式：(a) Prompt-time tool use（ReAct、ART, Paranjape 2023, arXiv:2303.09014）—— 给 demo 让模型 in-context 学；(b) Self-supervised fine-tuning（Toolformer, Schick 2023 NeurIPS, arXiv:2302.04761）—— 模型自己标 API call、用 loss 筛"有用的"；(c) Structured Function Calling（OpenAI 2023-06-13 / Anthropic Tool Use 2024 / Gemini Tools）—— RLHF/SFT 后端模型出 JSON-schema 结构化 tool call，最稳，是 2024-2026 工业部署默认范式。
5. Reflexion (Shinn et al. 2023, NeurIPS, arXiv:2303.11366)：在每个 episode 失败后让模型用自然语言反思（"verbal reinforcement"），把反思文本塞进 episodic memory，下一个 episode 把反思拼回 prompt → 不动权重就能在 HumanEval / AlfWorld 上明显涨点。不是 RL —— 没有 gradient update；本质是"用 in-context learning 模拟 policy iteration"。
6. MCP (Model Context Protocol, Anthropic 2024-11-25) 是 2025 工业事实标准：JSON-RPC 2.0 over stdio / Streamable HTTP，三类 primitive = tools（可执行）、resources（只读数据）、prompts（模板）。client/server 通过 initialize 协商 capability，之后用 tools/call / resources/read / prompts/get 调用。A2A (Google 2025-04, 2025-06 捐给 Linux Foundation；v0.3 + 2026Q1 已发布 v1.0) 互补：管 agent ↔ agent 协作（Agent Card at /.well-known/agent-card.json + Task lifecycle，v1.0 起 enum 改 SCREAMING_SNAKE_CASE）。一句话 mental model：MCP 管 agent → tool/data；A2A 管 agent → agent。
7. Computer-Use 范式 (2024-2025)：Anthropic Claude 3.5 Sonnet (new) 2024-10-22 首发，输入截屏，输出 {action: click/type/scroll, coordinates}；OpenAI Operator / CUA 2025-01-23（后并入 ChatGPT agent 2025-07-17）。GUI agent 把 OS 当 environment，bottleneck 在 grounding（坐标准不准）+ long horizon。
8. 2024-2026 主流 benchmark：SWE-bench (Jimenez et al. 2024 ICLR, arXiv:2310.06770) + SWE-bench Verified (OpenAI Preparedness team 2024-08-13, 500 人审子集)、GAIA (Mialon 2024 ICLR, 466 题, 人类 92% vs GPT-4 plugins 15%)、OSWorld (Xie 2024 NeurIPS, arXiv:2404.07972, 369 真实 OS 任务, 人类 72.36% vs GPT-4V baseline 12.24%)、WebArena (Zhou 2024 ICLR, arXiv:2307.13854, 812 web 任务, GPT-4 14.4% vs 人类 78.2%)、τ-bench (Yao 2024-06, arXiv:2406.12045, 客服域 + 用户 simulator)、AgentBench (Liu 2024 ICLR, 8 环境)、MLE-bench (Chan 2024-10, arXiv:2410.07095, 75 Kaggle 比赛)。Frontier 模型 + scaffold 在 SWE-bench Verified 上 2026Q1 已破 75-80%（OpenAI 在 2026-02-23 弃用该 benchmark，原因是 contamination + 测试 flaw），但 OS-level GUI / 真实长 horizon 任务仍远未饱和。
9. 生产架构关键模式：subagent orchestration（parent 派发子任务给隔离 context 的 child agent，结果汇总；Claude Code、Devin、Manus 都用这套）；tool retrieval（工具池 >100 时用 embedding top-k 过滤 schema，否则 prompt 爆炸）；KV-cache prefix sharing（多 agent 共享 system prompt）；token-budget guard / early termination（防 runaway loop 烧钱）。
10. 失败模式六连：(a) hallucinated tool call（调用不存在的函数或乱编参数）；(b) loop / stalemate（同一 action 反复触发）；(c) lost-in-context（agent 跑长后忘了 instruction）；(d) tool overuse / underuse（明明能直接答非要调 search）；(e) prompt injection via tool output（外部网页注入指令）；(f) reward hacking on benchmark（模型针对 grader 过拟合 surface pattern）。生产 mitigation = 结构化 tool schema + max_steps cap + observation truncation + Constitutional / safety classifier on tool I/O。

§1 Agent 的"最小可玩"心智模型

1.1　从 next-token predictor 到 agent

vanilla LLM 是 stateless function f: prompt → completion：一次性吃 prompt，吐 completion，没有外部交互。

Agent 把它包成一个 闭环系统：

        ┌──────────────────────────────┐
        │   LLM (policy π_θ)           │  ← 每一步看 history 出下一个 action
        └──────────────┬───────────────┘
                       │ action a_t
                       ↓
        ┌──────────────────────────────┐
        │  Environment / Tools         │  ← search / shell / browser / Python
        │  - retrieve(query)           │
        │  - python(code)              │
        │  - browse(url)               │
        └──────────────┬───────────────┘
                       │ observation o_t
                       ↓
        ┌──────────────────────────────┐
        │  Memory / Scratchpad         │  ← 把 (a_t, o_t) 追加进 context
        └──────────────┬───────────────┘
                       │ updated history
                       └──→ 回到 LLM

这就是 POMDP 的特例：state = 完整对话历史 $h_t = (q, a_1, o_1, \dots, a_{t-1}, o_{t-1})$，policy $\pi_\theta(a_t | h_t)$，trajectory 在 LLM 自己生成 Finish[answer] 时终止。

1.2　Agent 设计的三个正交维度

任何 agent 论文 / 框架都可以分解到三个独立轴：

面试时被问"你设计一个 X 的 agent"，先沿这三轴选定，再讨论实现细节，比直接吐架构图清晰得多。

1.3　与经典 RL agent 的对照

经典 RL agent（Atari、Mujoco）和 LLM agent 在结构上同源，区别：

LLM agent 的"诡异点"：action == token sequence，所以"call a tool"本质上是模型生成形如 Action: search("transformer") 的字符串，再由 harness 解析执行。Function Calling 的进步在于把这个 string 解析变成结构化 JSON，不再依赖正则。

§2 ReAct：Reason + Act 的祖宗 prompt

2.1　核心 prompt 模板

ReAct (Yao et al. 2022 arXiv preprint, ICLR 2023) 的关键发现：让模型显式输出 reasoning trace 和 action 交错，在 interactive decision 任务（ALFWorld、WebShop）+ 事实查证 (Fever) 上比 pure CoT 或 pure action-only 都强；在 multi-hop QA (HotpotQA) 上纯 ReAct 反而不及 pure CoT-SC（见下方 §2.2 表格），需要和 CoT-SC 互补 fallback 才发挥最强。

Question: <user question>
Thought 1: <reasoning about what to do>
Action 1: <tool_name>[<args>]
Observation 1: <tool output>
Thought 2: <reasoning about observation>
Action 2: <next tool call OR Finish[answer]>
Observation 2: ...
...
Thought N: I now know the answer.
Action N: Finish[<final answer>]

为什么交错很关键？因为：

• Reasoning 提供"为什么调这个工具 / 这个参数"的可解释 trace，模型能在下一步根据 reasoning 自己 debug；
• Action 提供外部信息，反过来 ground 后续 reasoning，避免一路幻觉；
• 比 Plan-then-Execute 多了一层"出错可改"——每一步 Thought 都能在前一步 Observation 后重新决策。

2.2　两种 prompt 变体对比（论文表格简化）

HotpotQA / Fever 列来自 Yao et al. ReAct 论文 Table 1 (PaLM-540B + 21-sample SC)；ALFWorld / WebShop 列来自论文 Table 3 / Table 4（不同 setup）。这里只是简化对照，看趋势用，精确数字以原论文为准。

• 在 HotpotQA EM 上，纯 ReAct (27.4) 低于纯 CoT (29.4) 和 CoT-SC (33.4)——"ReAct 全面碾压 CoT" 是常见误传；
• 论文最强的数字来自 ReAct ↔ CoT-SC 互补 fallback：HotpotQA 用 "ReAct → CoT-SC"（ReAct 不 confident 时切 CoT-SC）拿 35.1；Fever 用 "CoT-SC → ReAct" 拿 64.6——两个方向不同，看任务；
• ReAct 真正大幅领先的是 ALFWorld / WebShop 等 interactive decision-making 任务（绝对成功率 +34% / +10% vs IL/RL baseline）。这里"调外部工具"的价值才显著。

2.3　最小可运行实现（Python 伪代码 ~ 50 行）

import re
from typing import Callable, Dict

# ---- 外部依赖：替换成你自己的实现 ----
def search_engine(q: str) -> str: ...   # e.g. wraps Serper / Bing API
def kb_lookup(key: str) -> str: ...     # e.g. dict / DB lookup
def run_python(code: str) -> str: ...   # e.g. exec in sandboxed subprocess

# 工具池：每个工具就是 (name, fn, doc)
TOOLS: Dict[str, Callable[[str], str]] = {
    "search":   lambda q: search_engine(q),       # returns top-1 snippet
    "lookup":   lambda key: kb_lookup(key),
    "python":   lambda code: run_python(code),    # exec 隔离环境
    "finish":   lambda ans: ans,                  # sentinel
}

REACT_PROMPT = """You are a ReAct agent. At each step, output:

Thought: <reasoning>
Action: <tool>[<arg>]

Tools: search, lookup, python, finish.
End with Action: finish[<answer>].

Question: {question}
"""

ACTION_RE = re.compile(r"Action:\s*(\w+)\[(.+?)\]", re.DOTALL)

def react_loop(llm, question, max_steps=8):
    history = REACT_PROMPT.format(question=question)
    for step in range(max_steps):
        # 1) 让 LLM 续写一段（直到下个 "Observation:" 或 EOS）
        out = llm(history, stop=["Observation:", "Question:"])
        history += out

        # 2) 解析 action
        m = ACTION_RE.search(out)
        if not m:
            # 模型出格 → 强制终止（防 silent fail）
            return None, history, "parse_fail"
        name, arg = m.group(1).strip().lower(), m.group(2).strip()

        # 3) finish 出口
        if name == "finish":
            return arg, history, "ok"
        if name not in TOOLS:
            obs = f"[Error] Unknown tool {name}."
        else:
            try:
                obs = str(TOOLS[name](arg))[:512]      # 截断，防爆 context
            except Exception as e:
                obs = f"[Error] {type(e).__name__}: {e}"[:256]

        # 4) 把 observation 追加回 prompt
        history += f"\nObservation: {obs}\n"

    return None, history, "max_steps"

• stop=["Observation:", "Question:"] — 防止模型自己幻想 observation。没这步 ReAct 几乎一定崩。
• obs[:512] truncation — 长 search 结果会把 context 撑爆；生产里要么 truncate，要么再起一个 summarizer agent。
• [Error] ... 喂回去而不是 raise — 让 agent 有机会自己 recover；如果直接 raise，agent 没看到 error 不会调整 action。

2.4　常见 footguns（面试容易被问）

§3 Plan-and-Execute / Plan-and-Solve

3.1　核心思路

Plan-and-Solve (Wang et al. 2023 ACL, arXiv:2305.04091) 把推理拆成两阶段：

1. Plan：给定 question，模型先写出 N 步抽象计划（"Step 1: find X. Step 2: compute Y. Step 3: ..."），不执行；
2. Execute：按 plan 顺序执行，每步可以是 LLM 推理或调工具。

为什么 plan 单独一步有用？因为 LLM 写 plan 时不被 observation 干扰，更容易保持全局视角；而 ReAct 风格的 step-by-step 容易被前一步 observation 拽歪（"observation 说 X，那我下一步追 X"，忘了 user 原本问的是 Y）。

3.2　与 ReAct 的对照

生产架构里很少用纯 Plan-and-Execute，因为 plan 出错的代价高。主流做法是 hierarchical：高层 Plan-and-Execute（粗 plan），每步内部用 ReAct（细决策 + replan）。LangGraph、CrewAI、Anthropic 的 Claude Code subagent 都是这种 hybrid。

3.3　Plan repair 机制

纯一次性 plan 容易 fail；现代 agent 几乎都有 plan repair：

• Reflexion-style replan：execute 中失败 → 把失败描述塞回 prompt → 重新 plan；
• Tree-of-Thoughts plan tree：plan 本身就是 tree，每个分支独立 execute，verifier 评分回溯（Yao 2023 NeurIPS）；
• Step-wise replan：每 K 步重新 prompt 模型评估"现在 plan 还合理吗？需要改吗？"

§4 Reflexion：用语言做"伪 RL"

4.1　形式化

Reflexion (Shinn et al. 2023 NeurIPS, arXiv:2303.11366) 把 agent 行为分成三个模块：

• Actor $M_a$：生成 action（一个 ReAct 或 CoT agent）；
• Evaluator $M_e$：给 trajectory 打分（rule-based / heuristic / 另一个 LLM）；
• Self-Reflection $M_{sr}$：在 fail 后写一段自然语言反思，存入 episodic memory $\text{mem}$。

下一个 episode 时把 $\text{mem}$ 拼回 prompt。形式上像 policy iteration：

$$\tau_t \sim M_a(\cdot \mid q,\, \text{mem}_{

关键：$\theta$ 不变——只动 prompt 里的 reflection 文本。

4.2　为什么"语言 reflection"能 work？

把 reflection 当成 semantic gradient：

• 数值 gradient 告诉权重"往哪个方向移多少"；
• 语言 reflection 告诉 in-context policy "下次别这么做，应该这么做"——靠 in-context learning 在不动权重的情况下改变 effective policy；
• 类似 prompt tuning 但用自然语言、由模型自己生成。

需要强调：reflection 是 prompt-side adaptation，不是 weight update，所以效果对 base model capability 强依赖——base 写不出有用反思 / 写出错误反思时整套机制崩。论文 §5 也明确指出 Reflexion 在 ALFWorld / HumanEval / HotpotQA 上有效，但在 WebShop 上反思无法泛化到下一个 product search，未显著优于纯 ReAct。

4.3　性能数字（论文）

• Reflection rot：多个 episode 后 memory 越积越长，里面有过时甚至错误的反思，反而拖性能。生产里要做 reflection summarization / pruning。
• Self-evaluator drift：用 LLM 当 evaluator 时它会过宽（"这个答案不错啊"），导致永远不触发反思。论文里 HumanEval 用单元测试做 evaluator，AlfWorld 用环境 reward——rule-based evaluator 远比 LLM evaluator 稳。
• 不是所有任务都吃 reflection：论文自己报告 WebShop 上 Reflexion 没有显著优于 ReAct——因为 WebShop 任务需要 exploration breadth 而不是从单次失败中学规则，写出来的反思泛化不到下一个 product search。"Reflexion 通用"是常见误传。

4.4　最小实现骨架

# 假设我们对 §2.3 的 react_loop 做一个小扩展：允许传入 extra reflection memory
# 拼到 REACT_PROMPT 头部。signature：
#     react_loop(llm, question, max_steps=8, reflections: list[str] | None = None)
#     return (answer: str | None, history: str, status: str)
#
# evaluator 必须返回 (score: float, feedback: str)，
# 推荐用 rule-based（如单元测试 / 环境 reward），不要用 LLM-as-judge。

def build_reflection_block(memory: list[str]) -> str:
    """ 把累积的 reflection memory 拼成一段 system-level 头部 """
    if not memory:
        return ""
    items = "\n".join(f"- Past reflection: {r}" for r in memory)
    return (
        "Past attempts on this question failed. "
        "Use the following reflections to do better this time:\n"
        f"{items}\n\n"
    )

def reflexion_agent(llm, question, evaluator, max_episodes=3):
    """ Verbal RL: 不动权重，靠 reflection memory 改 prompt.
        Returns: (answer: str | None, history: str)
    """
    memory: list[str] = []                  # list of reflection strings
    last_answer, last_history = None, ""
    for ep in range(max_episodes):
        # 1) 跑一轮 ReAct（把 memory 作为 reflection prefix 传进去）
        answer, history, status = react_loop(
            llm, question, max_steps=8, reflections=memory
        )
        last_answer, last_history = answer, history

        # 2) 评分
        score, feedback = evaluator(answer, history, status)
        if score >= 1.0:
            return answer, history          # 成功，提前返回

        # 3) 让 LLM 自己反思失败（注意：reflection 自己也是一次 LLM call）
        reflection = llm(
            f"You failed: {feedback}\n"
            f"Your trajectory:\n{history}\n"
            f"Write a SHORT reflection (<60 words) on what to do differently."
        )
        memory.append(reflection)
    return last_answer, last_history        # 用尽 episode，返回最后一次

§5 Tool Use：从 prompt 到 structured function call

5.1　四代演进时间线

到 2024-2026，主流框架都已经站在第 3 代之上。MCP（§6）则在 transport 层标准化了 tool 的服务端实现。

5.2　Toolformer：自监督打标的核心 trick

Toolformer 想解决"如何让模型学会用 API 而无需人标"：

1. API 候选生成：让 base LLM 在每段文本的每个候选位置 emit [API(args)] token，先生成大量候选；
2. 执行 + 拼回：把每个候选 API call 真的去执行，结果 $r$ 拼到原文本里得到 $\text{text}_{\text{with}}$；

3. utility filtering（论文 §2.3）：对每个候选 API call $i$，定义三种条件下 LM 对继续 token 的加权 NLL：

   • $L_i^{+}$ = "调了 API + 拿到结果" 的 loss；
   • $L_i^{-}$ = $\min$(无 API call 的 loss, 调了 API 但 result 被替换成空的 loss)；

   保留满足 $$L_i^{-} - L_i^{+} \;\ge\; \tau_f$$ 的样本——也就是"调 API 且拿到结果"比"什么都不调 / 只调不读结果"都至少低 $\tau_f$。这个 $\min$ 是关键：它同时排除了"位置不该调"（无 call 已经够好）和"调了但结果没用"（光 call 不读 result）两种情况。$\tau_f$ 是超参（论文按 API 单独调，一般 0-1 量级）。

4. SFT：在过滤后的语料上 fine-tune base LLM。

5.3　Structured Function Calling 的 schema 规范

以 OpenAI Function Calling（2023-06-13）和 Anthropic Tool Use（2024 起）为代表，schema 长这样：

{
  "name": "get_weather",
  "description": "Get current weather in a given city.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "City name, e.g. Shanghai"},
      "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
    },
    "required": ["city"]
  }
}

模型推理时直接吐：

{"type": "tool_use", "name": "get_weather",
 "input": {"city": "Shanghai", "unit": "celsius"}}

前端框架解析后调用，再把结果包成 tool_result 块塞回 conversation history。

为什么比 ReAct text-protocol 强？

• JSON-schema validation：参数类型 / enum / required 都能在前端校验，错了直接拒绝；
• Parallel tool calls：一次推理出多个 tool_use block，并行执行（Anthropic 2024 起原生支持）；
• 决定性强：模型经过 SFT 对齐到 schema，几乎不会出语法错。

5.4　Parallel Tool Use 的注意点

# 调用方 (host) 端伪代码——需在 async 函数里 await
import asyncio

async def execute_tool(name: str, args: dict) -> str: ...   # 你自己的 dispatcher

async def parallel_tool_step(llm, conv) -> list[dict]:
    # 1) 一次 LLM 调用可能返回多个 tool_use block
    #    这里假设 llm 是 async client（如 anthropic.AsyncAnthropic / openai.AsyncOpenAI）
    response = await llm.messages.create(
        model="claude-opus-4-x", messages=conv, tools=[...]
    )
    tool_calls = [b for b in response.content if b.type == "tool_use"]

    # 2) 并行执行（注意：必须 idempotent / no-conflict 才能并行）
    results = await asyncio.gather(*[
        execute_tool(tc.name, tc.input) for tc in tool_calls
    ])

    # 3) 包成 tool_result 块塞回 conversation
    return [{"type": "tool_result", "tool_use_id": tc.id, "content": str(r)}
            for tc, r in zip(tool_calls, results)]

§6 MCP 与 A2A：2024-2026 的协议层标准

6.1　MCP (Model Context Protocol)

Anthropic 在 2024-11-25 开源了 MCP，到 2025 已经成为事实标准（OpenAI、Google、Microsoft 都在 2025 年支持）。一句话：MCP 是 "LSP for LLM" —— 让 host (Claude Desktop / Cursor / Cline / Claude Code) 通过统一协议接入任意 server (GitHub / Slack / Postgres / 自定义)。

6.1.1 三类 primitive

外加 sampling（server 可以反向请求 client 来一次 LLM call）和 roots（client 暴露文件系统根）。

6.1.2 Transport + 协议栈

• Wire format：JSON-RPC 2.0
• Transport：(a) stdio（本地 server，host 进程 fork-exec server）；(b) Streamable HTTP（HTTPS POST + SSE 双向流，2025 春升级版，替代旧的 HTTP+SSE）

• Lifecycle（2025-11-25 spec）：

  1. initialize request：client 报 protocol version + capabilities
  2. initialize response：server 报 capabilities + serverInfo
  3. initialized notification：握手完成
  4. 业务 method (tools/call, resources/read, prompts/get, etc.)
  5. Transport 关闭即终止——spec 明确不定义 shutdown message；stdio transport 关 stdin/stdout 即结束，HTTP transport 由 client 主动断连

6.1.3 Capability negotiation

// client → server
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-11-25",
  "capabilities":{"sampling":{}, "roots":{"listChanged":true}},
  "clientInfo":{"name":"claude-desktop","version":"1.x.y"}
}}

// server → client
{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-11-25",
  "capabilities":{
    "tools":{"listChanged":true},
    "resources":{"subscribe":true,"listChanged":true},
    "prompts":{"listChanged":true}
  },
  "serverInfo":{"name":"github-mcp","version":"0.x.y"}
}}

版本号是日期字符串（spec 自带 dated revisions：2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25），不是 semver。

6.1.4 安全模型（面试常被追问）

• Local stdio：进程隔离 + OS 权限，host 才能 spawn server，相对安全；
• Remote HTTP：走 OAuth 2.1（2025-03 spec 加入），加上 Authorization header；DCR (Dynamic Client Registration, RFC 7591) 在 2025-11-25 spec 已经从 SHOULD 降级到 MAY——客户端和授权服务器可以支持，但不再强制；同时引入 CIMD (Client ID Metadata Documents) 作为不需要预注册的另一条路；
• Prompt injection via tool/resource output：协议层无法防——MCP 把任意 content 直接塞回 LLM context，恶意 server 可以注入 "<system>Ignore previous instructions and ..."。生产 mitigation：(1) 在 host 端打安全标记 + 内容隔离 (sandbox content)；(2) 用 classifier 过滤 tool result；(3) 限制能拉起的 server 白名单。

6.2　A2A (Agent-to-Agent Protocol)

Google 在 2025-04 发布 A2A，2025-06-23 捐给 Linux Foundation。到 2026Q1 已经发布 v1.0——结构上比 v0.3 有几处不向后兼容的变更（Part 结构统一、enum 全部改 SCREAMING_SNAKE_CASE 如 TASK_STATE_SUBMITTED、ISO-8601 UTC 毫秒时间戳、引入 signed agent card / 多租户 / multi-protocol binding）。AgentCard 设计上保持向后可发现（agent 可以同时声明支持 v0.3 + v1.0）。本节以 v0.3 字段名讲解概念，v1.0 是上层 enum/命名差异，机制相同。A2A ↔ MCP 关系：MCP 让 agent 接入 tools / data；A2A 让 agent 接入其他 agent。

6.2.1 Agent Card

每个 A2A-compliant agent 在 /.well-known/agent-card.json 暴露一个 JSON：

// v0.3 风格示例（字段名以官方 spec 为准；这里只展示关键字段）
{
  "protocolVersion": "0.3.0",
  "name": "PurchasingAgent",
  "version": "1.0.0",
  "description": "Buys items from approved vendor catalogs.",
  "url": "https://agent.example.com/a2a",
  "preferredTransport": "JSONRPC",       // v0.3：声明主 transport
  "additionalInterfaces": [               // 同一 agent 可在多个 transport 上暴露
    {"transport": "GRPC", "url": "grpc://agent.example.com:50051"},
    {"transport": "HTTP+JSON", "url": "https://agent.example.com/a2a/rest"}
  ],
  "capabilities": {"streaming": true, "pushNotifications": true},
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {"id": "buy", "name": "Buy item", "description": "..."}
  ],
  "securitySchemes": {                    // v0.3：换成和 OpenAPI 一致的 schemes 形状
    "bearerAuth": {"type": "http", "scheme": "bearer"}
  },
  "security": [{"bearerAuth": []}]
}

Discoverable：另一个 agent 可以 GET /.well-known/agent-card.json 拿到能力描述，自动决定要不要委托任务。

6.2.2 Task lifecycle

A2A 的中心抽象是 Task，v0.3 状态机：

submitted ──→ working ──┬──→ completed
                        ├──→ failed
                        ├──→ canceled
                        ├──→ rejected
                        ├──→ input-required ──→ (user/agent reply) ──→ working
                        ├──→ auth-required ──→ (creds 提供) ──→ working
                        └──→ unknown   (心跳丢失 / 不可观测)

通信 wire = JSON-RPC 2.0（默认），v0.3 起也可选 gRPC 或 HTTP+JSON/REST（agent card 的 preferredTransport 字段声明）；可选 SSE 流式 + push notification。

6.2.3 MCP vs A2A 在架构里的位置

┌──────────────┐                              ┌──────────────┐
│ Host App     │                              │ Host App     │
│ (Claude /    │ ←── A2A (agent ↔ agent) ──→  │ (Other vendor│
│  Cursor)     │                              │  agent)      │
└──────┬───────┘                              └──────┬───────┘
       │ MCP (agent → tool/data)                     │ MCP
       ↓                                             ↓
┌──────────────┐  ┌──────────────┐         ┌──────────────┐
│ MCP server   │  │ MCP server   │         │ MCP server   │
│ (GitHub)     │  │ (Postgres)   │  ...    │ (Vendor DB)  │
└──────────────┘  └──────────────┘         └──────────────┘

6.3　最小 MCP server 骨架（Python）

# 用官方 SDK: pip install mcp
import asyncio
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent

app = Server("weather-mcp")

@app.list_tools()
async def list_tools() -> list[Tool]:
    return [Tool(
        name="get_weather",
        description="Get current weather for a city.",
        inputSchema={
            "type": "object",
            "properties": {
                "city": {"type": "string"},
                "unit": {"type": "string", "enum": ["c", "f"]}
            },
            "required": ["city"]
        }
    )]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name != "get_weather":
        raise ValueError(f"unknown tool: {name}")
    city = arguments["city"]
    unit = arguments.get("unit", "c")
    # 真实场景：调外部 API；这里返回 stub
    temp = 22 if unit == "c" else 71
    return [TextContent(type="text",
                        text=f"{city}: {temp}°{unit.upper()}")]

async def main():
    async with stdio_server() as (read, write):
        await app.run(read, write, app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(main())

Host 配置（Claude Desktop 风格）：

{
  "mcpServers": {
    "weather": {"command": "python", "args": ["weather_server.py"]}
  }
}

§7 工程模式：subagent / tool retrieval / memory / 预算

7.1　Subagent orchestration

随着任务变长，单一 agent 的 context window 撑不住。Subagent（aka delegated agent）的核心思想：parent agent 在某些步骤 fork 出一个 child agent，child 在独立 context 里完成子任务，只返回总结回来。

┌─────────────────────────────────────────────────────────┐
│ Parent agent  (system prompt + main goal)               │
│   step 1: ... [in-context]                              │
│   step 2: SPAWN(child, "research X and return summary") │
│           ↓                                              │
│           ┌──────────────────────────────┐              │
│           │ Child agent                   │              │
│           │  - 独立 context window        │              │
│           │  - 独立 tool set 可裁剪       │              │
│           │  - 跑完 N 步 → 返回 summary   │              │
│           └─────────────┬────────────────┘              │
│                         ↓                                │
│   step 2 result: "summary: ..."                          │
│   step 3: ... [continue with summary in main context]   │
└─────────────────────────────────────────────────────────┘

为什么这是关键架构？

• Context 隔离：child 内部探索失败、长 trace、噪声 observation 都不污染 parent 的 main context；
• Tool/permission scoping：child 可以拿到一个裁剪过的 tool set（如只允许 read-only），降低风险；
• 并行：parent 可以同时 spawn 多个 child（探索分支、A/B 比较）。

Anthropic 的 Claude Code 子代理、Cognition Devin、Manus 都是这套架构。

7.2　Tool retrieval：100+ 工具池

当工具池 ≥ 50-100 时，把所有 tool schema 塞进 system prompt 会出问题：

• Prompt 爆：每个 tool schema 100-200 token，100 个工具 = 10-20K token；
• 模型选择困难：LLM 在长 schema list 上选择 accuracy 下降；
• Cost：每次推理都要重过这 10-20K token。

解决方案：Tool retrieval——把 tool schema embedded 到 vector store，每次请求时：

import numpy as np

def embed(text: str) -> np.ndarray: ...   # 替换：OpenAI / Cohere / local embedder

def cosine(a: np.ndarray, b: np.ndarray) -> float:
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b) + 1e-9))

def select_tools(user_query: str, all_tools: list, top_k: int = 10):
    """ all_tools[i].embedding 假设已经预计算好（启动时算一次） """
    q_vec = embed(user_query)
    scored = [(t, cosine(q_vec, t.embedding)) for t in all_tools]
    return [t for t, s in sorted(scored, key=lambda x: -x[1])[:top_k]]

只把 top-k 工具的 schema 放进 prompt。可以选择再加 1-2 个"always-include"工具（如 finish、ask_user）作为 safety net。

• Query 是 prompt 第一句，但用户的真实意图可能要到第三段才说清楚 → 用 rewritten query（先让 LLM 重写 retrieval query）
• 多步任务的后续步用 step-1 retrieve 的工具不够，需要 dynamic re-retrieval 每 N 步重新选

7.3　Memory 架构

agent memory 通常分两层：

• Working memory 的 footgun 是 lost-in-the-middle（Liu et al. 2023, arXiv:2307.03172）—— 长 context 中段信息被忽略；mitigation 是 summarization + reordering（把关键事实 prepend 到最后）。
• Long-term memory 的 footgun 是 stale recall——retrieve 出来的旧记忆和当前任务冲突；mitigation 是 memory aging / decay 或 reflection 时主动 prune。

7.4　Token budget / early termination

生产 agent 必须有硬预算 guard：

import time

class BudgetGuard:
    def __init__(self, max_tokens=50_000, max_steps=20,
                 max_wall_clock_s=300, max_dollars=1.0):
        self.budgets = {"tokens": max_tokens, "steps": max_steps,
                        "time": max_wall_clock_s, "dollars": max_dollars}
        self.used = {k: 0 for k in self.budgets}
        self.t0 = time.time()

    def update(self, tokens_used=0, dollars_used=0):
        self.used["tokens"] += tokens_used
        self.used["dollars"] += dollars_used
        self.used["steps"] += 1
        self.used["time"] = time.time() - self.t0

    def should_stop(self) -> tuple[bool, str]:
        for k, v in self.used.items():
            if v >= self.budgets[k]:
                return True, f"budget_exceeded:{k}"
        return False, ""

    def graceful_finish(self, agent_state):
        """ 在 budget 到达前主动让 agent 总结当前进展并 Finish """
        # 比如：tokens 已用 80% → 注入 "You have limited time. Finalize."
        ...

§8 Computer-Use 范式：Agent as OS-user

8.1　接口对比

GUI agent（computer use / browser use）的核心 difference 是 action 不是文本工具调用，而是鼠标键盘操作：

Anthropic Claude 3.5 Sonnet (new) 2024-10-22 是 首个 frontier model 原生支持 computer use：API 暴露一个 computer tool，input 是当前截屏 + 任务，output 是 {action: "left_click", coordinate: [x, y]}，host 应用回放成 OS 事件。

8.2　两大 bottleneck

8.3　Benchmark 数字（2024-2026）

§9 复杂度、成本、容量规划

9.1　Token / Cost 模型

单次 agent 任务的成本可以建模为：

$$\text{Cost} \approx \sum_{t=1}^{T} \big[\, c_{\text{in}} \cdot |h_t| \;+\; c_{\text{out}} \cdot |y_t| \,\big]$$

• $T$ = 步数；
• $|h_t|$ = 第 $t$ 步 prompt 长度（含 system + 历史 trajectory $(a_1, o_1, \dots, a_{t-1}, o_{t-1})$ + 当前指令）；
• $|y_t|$ = 第 $t$ 步 LLM 输出 token 数 = thought 文本 + action 文本（与 §1.1 里的 observation $o_t$ 区分开，$y_t$ 是模型 own output，$o_t$ 是环境给的 observation）；
• $c_{\text{in}}, c_{\text{out}}$ 是 input / output 单价。

关键观察：$|h_t|$ 随 $t$ 线性增长（history 累加），所以总 cost 是 $O(T^2)$（每一步看到的 prompt 越来越长）。这就是为什么长 horizon agent 成本会爆。

缓解手段

9.2　Latency 模型

$$\text{Latency} \approx \sum_{t=1}^{T} \big[ T_{\text{LLM}}(t) + T_{\text{tool}}(t) \big]$$

通常 $T_{\text{LLM}}$ 包含 prefill（$\propto |h_t|$）+ decode（$\propto |y_t|$，受 TPS 限制；$y_t$ 是 §9.1 定义的当步 LLM 输出 token 数 = thought + action）。

9.3　Reliability：pass@k 与 verifier-driven retry

$$\text{Pass@}k = 1 - (1 - p_1)^k$$

其中 $p_1$ 是单次 success rate。如果 $p_1 = 0.5$，$\text{Pass@}5 \approx 97\%$。但前提是有一个 ground-truth verifier（unit test / 环境 reward / 人工）能可靠判断成败。

τ-bench (Yao 2024-06, arXiv:2406.12045) 的 $\text{pass}^k$（所有 k 次都对）远低于 $\text{pass@}k$（至少一次对），是 reliability 的更严苛指标——GPT-4o 在 retail 上 $\text{pass}^8 < 25\%$，意味着"一致地稳定做对"还差得很远。

§10 25 高频面试题（L1 必会 / L2 进阶 / L3 顶级 lab）

按 gpt-5.5 xhigh 模拟顶级 lab interviewer 视角排序。

L1 必会题（任何 LLM Agent 岗都会问）

L2 进阶题（agent 方向 / research 岗）

L3 高级题（顶级 lab / 研究方向）

§A 附录：核心 paper 时间线 + 一句话总结