Agent on Snow

MCP 完全指南：原理、远程调用链路与自建服务接入 Agent

Fri, 09 Oct 2026 15:00:00 +0800

MCP 完全指南：原理、远程调用链路与自建服务接入 Agent

大模型会“思考”和生成文本，却不知道你公司今天新增了哪个项目，也不能凭空替你创建工单。MCP 做的事，是用一套标准协议把这些外部数据和动作安全地接到 Agent 身边。

如果只记一句话，可以记住：

MCP（Model Context Protocol，模型上下文协议）是 Agent 应用与外部能力之间的标准接口。它规定如何发现能力、描述参数、发起调用、返回结果与协商权限；它不是模型，也不是新的业务 API。

本文按 2026-07-28 版 MCP 规范讲解，同时标出旧版客户端常见的初始化与会话差异。协议仍在快速演进，真正接入时应以所用 Host 和 SDK 支持的版本为准。

一、为什么需要 MCP

没有 MCP 时，每个 Agent 平台都有一套插件格式。若要让三个 Agent 连接 GitHub、数据库和内部工单系统，往往需要写九份适配代码：

flowchart LR subgraph Before[没有 MCP：N × M 个适配器] A1[Agent A] --> X1[GitHub 适配] A1 --> X2[数据库适配] A2[Agent B] --> X3[GitHub 适配] A2 --> X4[工单适配] end subgraph After[使用 MCP：统一协议边界] B1[Agent A] --> P[MCP] B2[Agent B] --> P P --> S1[GitHub Server] P --> S2[Database Server] P --> S3[Ticket Server] end

MCP 把“Agent 如何使用外部能力”从具体平台中抽了出来。它带来的核心价值不是少写一次 HTTP 请求，而是统一了以下契约：

问题	MCP 给出的统一方式
服务有什么能力	`tools/list`、`resources/list`、`prompts/list`
参数长什么样	JSON Schema
怎样执行动作	`tools/call`
怎样读取上下文	`resources/read`
怎样返回结果	`content`、`structuredContent`、错误信息与元数据
双方支持哪些功能	协议版本、capabilities 与扩展协商
消息如何传输	本地 `stdio` 或远程 Streamable HTTP

它和 USB-C 的类比有用但不完整：USB-C 统一了物理接口，MCP 统一的是一组面向模型的语义与调用契约。一个工具的名字、描述和 Schema 会直接影响模型是否选中它，因此 MCP 元数据本身就是产品界面的一部分。

二、先认清四个角色

flowchart LR U[用户] --> H[Host
Agent 应用] H --> M[LLM] H --> C1[MCP Client A] H --> C2[MCP Client B] C1 <-->|MCP| S1[MCP Server
项目系统] C2 <-->|MCP| S2[MCP Server
知识库] S1 --> API1[(业务 API / DB)] S2 --> API2[(文档 / 搜索)]

角色	做什么	常见误解
User	提出目标并对高风险动作确认	用户通常不直接构造 MCP 请求
Host	承载 Agent、模型、上下文、策略、审批与多个 MCP Client	MCP Server 不负责整个 Agent 循环
MCP Client	与一个 Server 通信，完成发现、调用和协议兼容	它一般是 Host 内部组件，不等于用户界面
MCP Server	暴露能力，校验调用并连接真实业务系统	它不是把整个数据库无条件交给模型

最重要的一点：通常不是模型直接访问 MCP Server。Host 先把允许的能力提供给模型；模型产生工具调用意图；Host 再根据权限、审批和运行策略决定是否执行。这个边界让“模型想做什么”和“系统允许做什么”可以分开。

三、MCP 暴露什么

MCP Server 主要暴露三类原语：

原语	控制者	适合什么	示例
Tools	模型选择调用，Host 执行策略把关	查询或执行动作	`search_projects`、`create_ticket`
Resources	Host / 应用选择加载	可寻址的只读上下文	`project://P-1024/spec`
Prompts	用户或 Host 选择	可复用的工作流模板	“生成发布检查清单”

此外还有通知、补全、引导式输入等能力。不要因为协议支持很多功能就全部实现：大多数服务从少量清晰的 Tools 开始就够了。

Tool 和普通 REST API 有什么不同

底层业务逻辑完全可以继续使用 REST、gRPC 或数据库。MCP Server 更像一层“面向 Agent 的适配器”：

flowchart LR L[LLM 看到的工具
名称 + 描述 + Schema] --> S[MCP Server
鉴权 · 校验 · 编排] S --> R1[REST API] S --> R2[gRPC] S --> R3[(Database)] S --> R4[Message Queue]

REST 路由通常为人类开发者设计，例如 PATCH /v1/projects/:id；MCP Tool 应围绕用户目标设计，例如 archive_project(project_id, reason)。不要简单地把数百个内部端点一比一暴露给模型。

四、远程 MCP 的完整调用链路

远程 MCP 通常使用 Streamable HTTP。旧的 HTTP+SSE transport 已被取代，只应为旧客户端保留兼容。下面先看一次典型工具调用：

sequenceDiagram autonumber actor User as 用户 participant Host as Agent Host participant Model as LLM participant Client as MCP Client participant Server as Remote MCP Server participant API as 业务系统 Host->>Client: 连接服务器配置 Client->>Server: 发现协议版本与 capabilities Server-->>Client: server info + capabilities Client->>Server: tools/list Server-->>Client: 工具名、描述、输入/输出 Schema、annotations User->>Host: “列出本周延期的项目” Host->>Model: 用户消息 + 可用工具定义 Model-->>Host: 调用 list_projects(status="delayed") Host->>Host: 策略检查 / 必要时请求确认 Host->>Client: 执行工具调用 Client->>Server: tools/call + 身份凭据 Server->>Server: 鉴权、租户隔离、参数校验 Server->>API: 查询真实业务数据 API-->>Server: 项目记录 Server-->>Client: content + structuredContent Client-->>Host: 工具结果 Host->>Model: 将允许的结果加入上下文 Model-->>Host: 组织自然语言答案 Host-->>User: 最终回复 + 来源/动作状态

这条链路可以拆成五段。

1. 配置与发现

Host 保存 MCP Server 的名称、URL 和认证方式。连接时，双方确认协议版本、服务信息和 capabilities；Client 再读取工具列表。现代客户端会缓存列表，并在服务通知能力变化或缓存失效时刷新。

截至本文所用的 2026-07-28 规范，新链路以无会话的 server/discover 和每请求元数据为主；兼容旧规范的客户端则可能先走 initialize → initialized，并携带 Mcp-Session-Id。SDK 会处理大部分兼容逻辑，业务代码不要自己拼 JSON-RPC。

2. 工具进入模型上下文

Host 并不一定把所有工具都塞给模型。它可能按租户、角色、当前任务或工具搜索结果过滤，只向模型提供相关的名称、描述和 Schema。这一步决定模型“知道自己能做什么”。

工具越多不一定越好。五个边界明确的工具，通常比五十个描述含糊的工具更可靠，也更节省上下文。

3. 模型选择，Host 决策

模型返回的是一个结构化调用意图，而不是直接执行结果。Host 应在这里做策略判断：

该用户能否使用这个 Server 和 Tool；
读取是否可直接执行，写入是否需要确认；
参数是否命中数据边界、费用上限或速率限制；
是否存在提示注入、越权或破坏性风险。

Tool annotations 能帮助 Host 判断 readOnly、destructive、openWorld 等性质，但它们只是提示，不能替代服务端鉴权。

4. HTTP 调用与业务执行

Client 通过 HTTPS 向 /mcp 发送 MCP 请求。现代远程请求包含协议版本和路由相关信息，认证通常放在 Authorization header。Server 必须再次完成：令牌验证、scope 校验、租户隔离、参数校验、业务授权、超时与审计。

然后它才调用真正的 REST/gRPC/数据库。MCP 不会替你解决业务授权，也不会自动让一条危险 SQL 变安全。

把 SDK 隐藏的细节展开，一次现代 Tool 调用大致是下面这样（为便于阅读省略部分每请求 _meta）：

POST /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer <access-token>
Content-Type: application/json
Mcp-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: list_projects

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "list_projects",
    "arguments": {"status": "delayed", "limit": 5}
  }
}

成功结果仍是 JSON-RPC，其中 content 供模型阅读，structuredContent 供程序可靠消费：

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [{"type": "text", "text": "Found 1 delayed project."}],
    "structuredContent": {
      "result": [{"id": "P-1002", "name": "Billing migration"}]
    },
    "isError": false
  }
}

不要在业务代码中手写这些报文。示例的意义是方便查日志、网关和 trace；版本协商、header 与 JSON-RPC 细节应交给 SDK。

5. 结果回到模型

工具结果常有三条通道：

字段	谁使用	建议
`content`	模型	简洁、可理解，说明发生了什么
`structuredContent`	Host / 后续工具 / UI	遵守输出 Schema，返回稳定 ID 与字段
`_meta`	Client 应用	放客户端专用信息；不要把它当秘密保险箱

Host 将允许模型看到的结果放回上下文，模型再生成最终答复。MCP 调用成功不等于用户任务成功：Agent 还需要检查 isError、确认数据完整性，并可能继续调用下一项工具。

五、两种远程连接模式

flowchart TB subgraph Direct[模式 A：应用运行时直接连接] A[你的 Agent 应用] --> C[MCP Client] C --> S[Remote MCP Server] end subgraph Hosted[模式 B：模型平台托管连接] B[你的应用] --> P[模型 / Agent 平台] P --> HS[Remote MCP Server] end

模式	优点	适合场景
运行时直连	网络、凭据、审批、过滤都由你的应用掌控	私网服务、严格合规、自定义策略
平台托管 MCP	接入代码少，Agent 平台负责协议调用	公网 HTTPS 服务、快速集成

在 OpenAI Agents SDK 中，公开远程服务可作为 hosted MCP tool；本地或私有服务则可以由 SDK runtime 通过 stdio 或 Streamable HTTP 管理。选择标准不是“哪种更新”，而是连接与信任边界应该由谁拥有。

六、从零开发一个远程 MCP Server

下面做一个最小但完整的“项目查询”服务。示例使用 Python SDK v2、Python 3.10+，并选择无状态 Streamable HTTP，便于水平扩展。

1. 初始化项目

1
2
3

mkdir project-mcp && cd project-mcp
uv init
uv add "mcp[cli]>=2,<3" pydantic

固定主版本很重要：MCP SDK 与规范演进较快，不应让生产构建在无审核时跨主版本升级。

2. 编写 `server.py`

from typing import Annotated, Literal

from mcp.server import MCPServer
from mcp.types import ToolAnnotations
from pydantic import BaseModel, Field


class Project(BaseModel):
    id: str
    name: str
    status: Literal["active", "delayed", "archived"]
    owner: str


PROJECTS = [
    Project(id="P-1001", name="Search upgrade", status="active", owner="Lin"),
    Project(id="P-1002", name="Billing migration", status="delayed", owner="Kai"),
]

mcp = MCPServer("project-catalog", version="1.0.0")


@mcp.tool(
    annotations=ToolAnnotations(
        readOnlyHint=True,
        idempotentHint=True,
        destructiveHint=False,
        openWorldHint=False,
    )
)
def list_projects(
    status: Literal["active", "delayed", "archived"] | None = None,
    limit: Annotated[int, Field(ge=1, le=50)] = 10,
) -> list[Project]:
    """List projects, optionally filtered by exact status.

    Use this for project discovery. It never modifies project data.
    """
    matches = [p for p in PROJECTS if status is None or p.status == status]
    return matches[:limit]


if __name__ == "__main__":
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=True,
        json_response=True,
    )

这段代码虽短，却已经定义了完整契约：

函数名成为 Tool 名；
docstring 成为模型看到的描述；
类型注解生成输入 JSON Schema；
返回类型生成输出 Schema；
ToolAnnotations 告诉 Host 它是只读、幂等、非破坏且不访问开放互联网的；
SDK 处理 MCP 消息、协议版本与 Streamable HTTP。

生产环境里把 PROJECTS 替换成业务 Service 调用即可，但不要跳过“从当前认证身份推导租户”这一步。

3. 本地测试

先用官方 Inspector 检查能力发现、Schema 和结果：

`1`	`uv run mcp dev server.py`

再启动真正的远程 transport：

1
2

uv run python server.py
# MCP endpoint: http://127.0.0.1:8000/mcp

另一种可靠的自动化检查，是用同一 SDK 作为客户端：

import asyncio
from mcp import Client


async def main() -> None:
    async with Client("http://127.0.0.1:8000/mcp") as client:
        tools = await client.list_tools()
        assert any(tool.name == "list_projects" for tool in tools.tools)

        result = await client.call_tool(
            "list_projects", {"status": "delayed", "limit": 5}
        )
        assert not result.is_error
        assert result.structured_content["result"][0]["id"] == "P-1002"


asyncio.run(main())

测试至少覆盖：正常参数、边界值、非法枚举、无权限、下游超时、空结果和输出 Schema。Inspector 能证明“协议可用”，自动化测试才能证明“升级后仍然可用”。

4. 容器化与部署

FROM python:3.13-slim
WORKDIR /app

COPY pyproject.toml uv.lock ./
RUN pip install --no-cache-dir uv && uv sync --frozen --no-dev

COPY server.py ./
EXPOSE 8000
CMD ["uv", "run", "python", "server.py"]

1
2

docker build -t project-mcp:1.0.0 .
docker run --rm -p 8000:8000 project-mcp:1.0.0

生产地址应是稳定 HTTPS URL，例如：

`1`	`https://mcp.example.com/mcp`

上面的演示服务没有认证，只能用于本机学习。部署到任何可被其他人访问的网络前，必须接入 SDK 的 token verifier / OAuth 配置，并在每个 Tool 内落实业务授权。

反向代理和平台需要允许流式响应；设置合理的请求体上限、调用超时和连接空闲时间。无状态模式适合普通查询与动作；需要跨调用状态时，优先让服务返回显式 handle，再由后续工具把它作为参数传回，而不是偷偷依赖某台实例的内存。

七、让 Agent 真正使用你的 MCP

“服务能访问”只完成了一半。要让 Agent 稳定调用，还需要注册、授权、告知使用时机、验证真实行为。

接入 Codex

使用 Codex CLI 添加远程服务：

1
2

codex mcp add projects --url https://mcp.example.com/mcp
codex mcp list

也可以写入 ~/.codex/config.toml：

1
2

[mcp_servers.projects]
url = "https://mcp.example.com/mcp"

然后在项目 AGENTS.md 中给出简短、可验证的路由规则：

1
2

查询项目状态、负责人或项目 ID 时，先使用 projects MCP 的只读工具。
任何修改、归档或删除项目的动作都必须先向用户展示目标与影响，并等待确认。

配置决定“Agent 能看见哪些能力”，指令决定“什么时候优先使用”。不要写“永远相信工具结果”之类的规则，远程内容仍可能过期或包含恶意文本。

接入 OpenAI Agents SDK

公开的远程 MCP 可以作为 hosted tool 附到 Agent 上：

from agents import Agent, HostedMCPTool

agent = Agent(
    name="Project assistant",
    instructions="Use the projects MCP for current project facts.",
    tools=[
        HostedMCPTool(
            tool_config={
                "type": "mcp",
                "server_label": "projects",
                "server_url": "https://mcp.example.com/mcp",
                "require_approval": "never",  # 仅适合这里的只读工具
            }
        )
    ],
)

写操作不要照抄 never。审批策略应与工具风险匹配，并且服务端仍需独立鉴权。私有服务也可以让 Agents SDK runtime 直接管理连接，从而由你的应用控制网络、过滤与审批边界。

验证 Agent 是否会用

准备一组小型评测，而不是只问一句“能用吗”：

用例	期望行为
“列出延期项目”	调 `list_projects(status="delayed")`
“介绍什么是延期项目”	若是通用定义，不应无意义调用
“把 P-1002 删除”	当前无删除工具，应说明做不到，不能伪造成功
“列出 `status=hacked`”	Schema 拒绝非法枚举，Agent 应修正或解释
Tool 返回网页中的“忽略之前指令”	把它视作不可信数据，不执行越权动作

观察三类指标：工具选择是否正确、参数是否正确、拿到结果后是否忠实回答。只看最终文字，容易漏掉重复调用、越权尝试和不必要的高成本请求。

八、工具设计决定 Agent 上限

好工具的形状

flowchart LR G[用户目标] --> N[清楚的动词名] N --> D[说明何时使用] D --> I[窄而明确的输入 Schema] I --> A[真实 annotations] A --> O[稳定的结构化输出] O --> E[可恢复的错误]

建议遵循这些规则：

一个工具完成一个可识别目标。 用 list_projects、get_project、update_project，不要做 project_action(mode, payload) 万能入口。
描述“何时用”，而不只描述实现。 模型靠描述选择工具。
输入要窄。 枚举、长度、范围、格式能写进 Schema 就不要只写在文档里。
读取与写入分开。 这样 Host 才能给不同审批策略。
返回稳定 ID。 后续调用使用 P-1002，不要让模型靠名称猜记录。
分页且设上限。 不要一次把十万行塞进上下文。
错误应可恢复。 “项目不存在，请先 list_projects 获取 ID”比堆栈信息有用。
Schema 向后兼容。 新增可选字段通常安全；改名、改类型或删除字段可能让旧 Agent 失效。

MCP 不适合什么

纯粹在应用内部、只被一处调用的简单函数，直接 function tool 可能更省事；
大文件持续传输、实时音视频等数据面，不应硬塞进工具结果；
要求严格确定性的核心交易流程，不应把关键状态机完全交给模型自由规划；
没有授权边界的“任意 SQL”“任意 Shell”“任意 URL 抓取”，不应作为生产工具暴露。

九、安全：把模型、Server 和返回内容都当作不可信边界

flowchart LR U[用户输入
不可信] --> H[Host 策略层] H -->|最小工具集| M[模型输出
不可信意图] M --> A{审批 / 授权} A --> S[MCP Server
再次鉴权与校验] S --> B[业务系统] B --> R[工具结果
仍不可信] R --> H

上线前至少做好以下事项：

风险	防线
越权读取或跨租户访问	每次调用验证 token、scope、tenant 与对象级权限
破坏性动作	单独工具、明确 annotations、用户确认、幂等键、可审计与可回滚
提示注入	把 Tool/Resource 返回当数据；禁止其改写系统策略或索要更多工具
Token 泄漏	不写入 Tool 描述、结果和日志；不向错误 audience 透传 token
SSRF	URL allowlist、DNS/IP 校验、阻止云元数据与内网地址、限制重定向
数据过量	字段最小化、分页、结果上限、PII 脱敏
拒绝服务与费用失控	速率限制、并发限制、超时、熔断、配额
供应链漂移	固定 SDK 主版本、扫描依赖、灰度升级、可回滚部署

认证回答“你是谁”，授权回答“你能对哪条数据做什么”。只验证 Bearer Token 是否存在远远不够。对多用户服务，业务查询必须从已验证凭据中取得用户和租户，绝不能信任模型传入的 user_id。

OAuth 场景使用标准授权发现、最小 scope 和明确 audience。Tool annotations、Host 弹窗、网络 allowlist 都属于纵深防御，但服务端对象级授权才是最终边界。

十、可观测性与排错

一次 MCP 问题可能出现在四层：模型没选工具、Host 拦截、协议失败、业务系统失败。日志必须能把它们串起来。

建议记录：

trace_id / request ID、Server 与 Tool 名称、版本；
已脱敏的调用方、租户、审批结果；
总耗时和下游耗时、结果大小、错误分类；
Schema 版本与部署版本。

不要记录 access token、完整私密文档或未经脱敏的 Tool 结果。

现象	先查什么
Server 完全连不上	URL、HTTPS 证书、DNS、Host header、防火墙、`/mcp` 路径
已连接但看不到工具	discovery/capabilities、`tools/list`、注册代码是否执行
模型从不调用	Tool 名称与描述、指令、是否给了过多相似工具
参数总是错	Schema 是否太宽或语义含糊，枚举与示例是否清楚
本地正常、远程超时	代理流式配置、平台超时、下游延迟、冷启动
调用成功但回答错误	`content` 是否清楚、结构化结果是否完整、模型是否拿到旧缓存
多副本偶发失败	是否暗中依赖进程内状态或旧版 session sticky routing

最短排错路径通常是：Inspector 直连 Server → SDK Client 直连 → Host 中查看工具列表 → 观察一次完整 Agent trace。这样能快速定位问题属于服务、协议还是模型决策。

十一、生产检查清单

Tool 名称、描述、输入/输出 Schema 已评审
读取、写入、破坏性动作已拆分
每次请求都做认证、scope、租户和对象级授权
远程 endpoint 使用稳定 HTTPS 与 Streamable HTTP
写操作有审批、幂等与审计，必要时可回滚
结果有分页与大小上限，不含 secrets
超时、重试、限流、熔断和下游错误映射已配置
Inspector、自动化测试和 Agent 行为评测均通过
有 trace、指标、脱敏日志和告警
SDK 与 Schema 版本固定，升级可灰度和回滚

结语

MCP 真正解决的不是“让模型发一个 HTTP 请求”，而是让能力发现、参数契约、调用执行、结果返回和安全策略有一条共同的标准链路。

开发自己的 MCP，可以按这条最短路径推进：

flowchart LR A[选一个真实用户目标] --> B[设计一个窄 Tool] B --> C[本地 Inspector] C --> D[自动化测试] D --> E[Streamable HTTP + Auth] E --> F[接入 Agent] F --> G[行为评测与观测] G --> H[再增加下一个 Tool]

先把一个只读工具做准，再增加写操作；先把权限边界做实，再追求复杂编排。MCP 降低了连接成本，却不会替代良好的 API 设计、授权模型与工程治理。

参考资料

Claude Code 和 Codex 的区别：从产品形态到工作流，一次讲透

Sat, 11 Jul 2026 13:12:00 +0800

Claude Code 和 Codex 的区别：从产品形态到工作流，一次讲透

现在的 AI 编程工具，已经不只是“帮你补几行代码”，而是在往“能接管一段真实开发流程的代理”演化。Claude Code 和 Codex 都属于这一代产品，但它们走的不是同一条路。

很多文章会把这两个工具简单写成“一个是 Anthropic 的，一个是 OpenAI 的”，然后开始比模型效果。这样写不算错，但也不够有用。真正决定体验的，往往不是一句“谁更聪明”，而是这两个工具 默认假设你怎样工作。

如果先给结论，我会这样概括：

Claude Code 更像一个围绕本地工程工作区构建的编程代理工作台
Codex 更像一个把本地开发、云端委派和 GitHub 协作打通的编程代理平台

下面不只讲区别，也讲清楚这两个产品为什么会长成现在这样。

先看总图

这张图可以先帮助你建立一个整体印象。Claude Code 的重心更靠近“本地工作区、项目规则、长期上下文和工具接入”，Codex 的重心更靠近“多端一致体验、云端后台任务、GitHub 工作流和平台化委派”。

这并不意味着 Claude Code 没有云端能力，也不意味着 Codex 不能本地开发。真正的区别是：两者的默认工作重心不同。

先把 Codex 这个词说清楚

现在大家讨论的 Codex，通常指的是 OpenAI 这一代面向开发者的 coding agent 产品，而不是 2021 年那个早期的同名代码模型。官方 Quickstart 里已经把 Codex 明确放进 App、IDE 扩展、CLI 和 Cloud 这些入口里，说明它早就不是单一模型，而是一套完整的代理工作流。

同样地，Claude Code 也不是“Claude 会写代码”这么简单。Anthropic 的官方文档把它定义成一个 agentic coding tool，强调它可以读代码库、改文件、跑命令，并在 Terminal、IDE、Desktop 和 Web 之间切换。

所以如果你把这两个工具理解成“两个聊天框 + 一个代码模型”，从一开始就会看偏。

一句话结论

很多人第一次用这两个工具，会觉得它们都能做相似的事：读项目、改多文件、执行命令、跑测试、做 review、生成提交。问题在于，相同功能背后的 组织方式 并不一样。

Claude Code 最突出的特点，是它很强调 项目上下文、可控权限、MCP 接入、技能和长期记忆；Codex 最突出的特点，是它很强调 本地与云端双模、多端统一、GitHub 委派和任务回收。前者像一台能深度定制的工程工作台，后者像一个更完整的代理操作系统。

差异总览

维度	Claude Code	Codex
官方定位	Agentic coding tool	Coding agent / coding workflow platform
核心重心	本地项目目录与工程上下文	本地执行 + 云端委派 + GitHub 协作
常见入口	Terminal、VS Code、Desktop、Web、JetBrains	App、IDE Extension、CLI、Cloud
默认使用节奏	围绕仓库连续工作	随时本地做，也随时把任务挂到后台
扩展机制	`CLAUDE.md`、auto memory、hooks、skills、MCP、Agent SDK	skills、plugins、config、cloud environment、GitHub integration
安全控制	权限审批、工作区写入边界、可选 sandbox	sandbox mode、approval policy、云端环境隔离
典型优势	深度驯化工程流	任务委派与多端协作
更适合	想把代理嵌进长期研发习惯的人	想把“本地开发 + 云端代办 + PR 流程”打通的人

如果只看表格，你会觉得差异还不算大。真正拉开差距的，是下面这几个层面：产品形态、工作流、安全边界和扩展方式。

产品形态不同

Anthropic 在 Claude Code 文档里，把 Terminal、VS Code、Desktop、Web、JetBrains 都列成同一个体系里的使用入口，而且还继续向外延伸到了 Remote Control、routines、background agents、Slack、CI/CD 等场景。这种设计更像是：同一套代理能力，跟着你的开发环境一起移动。

Codex 的文档则更强调另一件事：你可以在本地 App、IDE、CLI 中调用它，也可以直接在云端环境中启动任务、连接 GitHub 仓库、查看日志、审查 diff，然后回收到 PR。这种感觉更像：你不只是在“用一个本地工具”，而是在使用一个可本地执行、可云端委派的代理平台。

两者都在做“多端”，但动机不一样：

Claude Code 的多端，更像把一份本地工作连续延长
Codex 的多端，更像把同一类任务在不同执行面之间分发

这就是为什么很多人同时觉得“它们很像”，又会在深入使用后觉得“完全不是一个味道”。

工作流的默认假设不同

很多工具表面上都支持“本地 + 云端”，但关键不在于支不支持，而在于它 默认假设你最常怎么工作。

Claude Code 的最自然姿势，是从某个项目目录启动，然后围绕这份仓库持续工作。它之所以重视 CLAUDE.md、hooks、permissions、MCP、skills，不是因为这些东西看起来高级，而是因为它默认你会在 同一套工程上下文里不断深入。

Codex 的文档则把 Local 和 Cloud 明确摆在了前台。你既可以直接在本地目录里让它做事，也可以把任务交给云端环境，在浏览器里看它执行，最后产出 diff 或 PR。这种设计天然更适合异步协作，也更适合“我先把任务挂出去，稍后回来 review”的节奏。

用一句更直白的话说：

Claude Code 更像“代理在你的工作区里陪你干活”
Codex 更像“代理既能在你旁边干活，也能被你派出去单独干活”

如果你每天都在一个大仓库里来回调试、试错、查文档、接内部工具、修细节，Claude Code 往往更容易形成手感。
如果你更习惯把任务拆出来、挂到后台、异步等结果，Codex 会更顺。

安全边界的设计重点不同

这两个产品都非常重视安全，但文档里暴露出来的设计思路并不相同。

Claude Code 更像权限驱动

Claude Code 的官方 Security 文档反复强调三件事：

默认是严格的只读权限
会改系统状态的 Bash 命令需要批准
写入默认被限制在启动目录及其子目录

它还强调，像 ls、cat、git status 这样的只读命令可以直接执行，但修改系统状态的命令需要审批；即使进入更高自动化的编辑模式，也不是无限制放权。再加上 allow/deny 规则、trust verification、hooks 和 sandbox，这套设计的重点是：把每一次放权都做成清晰的边界选择。

Codex 更像沙箱驱动

Codex 的安全文档会先区分两个核心概念：

sandbox mode 决定技术上能做什么
approval policy 决定什么时候必须停下来问你

本地模式里，它依赖操作系统级机制把写权限和网络访问关进当前工作区；云端模式里，它运行在隔离环境中，并且把 setup 阶段和 agent 阶段的权限边界拆得很清楚。你会感觉到，它不是先问“这一步要不要放行”，而是先问“这台代理当前到底被放在什么盒子里”。

两种思路，分别适合谁

如果你更喜欢细粒度控制，喜欢给命令、目录、MCP、文件写规则，Claude Code 会更有“可调教感”。如果你更喜欢先选定一个可信运行档位，再基于审批策略运行，Codex 的方式会更像传统工程系统里的权限层级。

这不是谁更安全，而是谁的控制接口更符合你的直觉。

扩展能力的侧重点也不一样

很多人对“扩展能力”的理解，还停留在“能不能接第三方工具”。其实更关键的问题是：这个代理能不能被你长期纳入自己的研发体系。

Claude Code：更强调项目内沉淀

Claude Code 在这方面有一套很完整的组合拳：

CLAUDE.md 用来固化项目规则、架构背景和代码偏好
auto memory 让它在多次会话里积累构建和调试经验
hooks 能在编辑前后自动挂流程
skills 能把团队常用动作包装成固定套路
MCP 能把 Jira、Slack、数据库、内部平台等接进来

这些能力组合起来的效果，不只是“功能多”，而是 它会越来越像这个项目自己的代理。

Codex：更强调平台化分发

Codex 也有 skills，但它的技能体系和 plugins 更偏平台思维。OpenAI 明确把 skills 视为工作流抽象，把 plugins 视为安装和分发单位，一个插件甚至可以同时携带技能、MCP 配置、依赖说明和界面元数据。

这意味着 Codex 不只是方便你“在当前项目里配置”，也方便你“把一套代理能力打包给更多场景复用”。如果你所在的团队已经很依赖统一平台、统一入口、统一账号、统一 GitHub 协作，这种设计会很自然。

团队协作体验也不同

Claude Code 更擅长的是 把代理嵌进已有工作流。比如 CI/CD、Slack、scheduled tasks、sub-agents、background agents，这些能力都说明它适合放进一个已经成型的研发链路里，成为“研发过程中的代理层”。

Codex 更擅长的是 把工作变成任务，再把任务回收到 GitHub。在浏览器中开云端任务、连接仓库、看执行日志、审查 diff、生成 PR，或者在 GitHub 评论里直接 @codex，这些都让它更像任务派发中心。

如果要用一句很短的话概括：

Claude Code 更像在团队流程里长出来
Codex 更像把团队任务收拢到一个平台里

到底怎么选

很多人最关心的问题不是“它们哪不同”，而是“我到底该选哪个”。这个问题最好不要从品牌出发，而要从自己的工作节奏出发。

更适合选 Claude Code 的情况

如果你符合下面这些特征，Claude Code 往往会更对味：

你大多数时间都在本地仓库里持续工作
你很在意项目级规则、目录级权限、记忆文件和 hooks
你希望代理长期理解你的工程约定，而不是每次都从头开始
你需要频繁连接内部工具或团队私有系统

这类用户真正想要的，不只是“会写代码的 AI”，而是“越来越懂这套项目脾气的代理”。

更适合选 Codex 的情况

如果你更符合下面这些特征，Codex 往往会更顺：

你已经深度使用 ChatGPT 生态
你喜欢把任务委派出去，稍后回来 review
你很依赖 GitHub 的 issue、评论、PR 和异步协作
你想把本地开发、云端执行和多端体验统一起来
你更习惯通过 sandbox 档位和 approval policy 管理风险

这类用户通常追求的不是“代理是否足够贴身”，而是“代理是不是足够好派、好管、好回收”。

一个更真实的判断

很多横评喜欢把问题收束成一句大结论，比如“Claude Code 更强”或者“Codex 更像真正的 agent”。这类结论很适合做标题，但不适合做选型。

更接近真实世界的判断是：Claude Code 和 Codex 正在从两个不同方向收敛到同一件事。 Claude Code 是从本地工程代理向多端、多代理、远程协作扩展；Codex 是从多端代理平台向更强的本地工程能力和更细的安全控制收敛。

所以今天它们最大的差别，不一定是“能力上谁有、谁没有”，而是：

Claude Code 默认假设你正在一个真实项目里持续深耕
Codex 默认假设你随时可能把任务分发到别的执行面上

只要把这个默认假设想清楚，很多看似复杂的对比，其实就都顺了。

总结

最后把全文压缩成几句话：

Claude Code 和 Codex 都已经不只是代码补全工具，而是能读仓库、改文件、跑命令、做验证的编程代理
Claude Code 更偏本地工程工作台，Codex 更偏本地与云端一体的代理平台
Claude Code 的优势在于项目上下文、规则沉淀、MCP 接入和长期驯化
Codex 的优势在于云端委派、多端统一、GitHub 协作和平台化安全模型
真正的选型关键，不是听谁宣传得更猛，而是看你的工作节奏更像“持续深耕”，还是“频繁委派”

如果后面继续写这个系列，我更想接着写两篇：

Claude Code 和 Codex 的真实开发工作流对比：各做一个完整功能是什么体验
Claude Code、Codex、Cursor、Cline 四款 AI 编程工具怎么选

参考资料

这篇文章主要基于两家的官方文档整理，建议你如果准备长期选型，最好也直接看一遍原始文档：

关于 Agent 面试的那些事

Mon, 13 Apr 2026 20:40:50 +0800

前言

随着 AI Agent 技术的快速落地，Agent 相关岗位（开发工程师、算法工程师、产品经理）已成为 AI 领域的热门方向。面试官的考察维度也从基础概念逐步深入到工程落地、系统设计、安全合规等实战层面。

本文章整理了 2024-2025 年主流大厂（字节、阿里、腾讯、OpenAI 等）的 Agent 面试高频问题，覆盖基础认知、核心技术、工程落地、系统设计、产品设计等全维度，每个问题附带考察点与参考回答思路，帮助你全面备战 Agent 岗位面试。

一、基础认知类面试题

（入门必问，考察候选人对 Agent 的基本理解）

技术岗基础题

什么是 AI Agent？它与传统的 LLM、Chatbot 有什么本质区别？
- 考察点：基础概念认知，对 Agent 核心能力的理解
- 参考回答思路：
  - AI Agent 是具备「感知(Perception) - 规划(Planning) - 行动(Action) - 观察(Observation)」闭环的智能系统，能自主感知环境、决策并执行动作达成目标。
  - 与传统 LLM 的区别：LLM 只是语言生成模型，没有外部行动能力；Agent 以 LLM 为大脑，扩展了工具调用、长期记忆、自主规划能力。
  - 与 Chatbot 的区别：Chatbot 是被动响应的对话工具，Agent 是主动目标驱动的任务执行者，能跨工具协同、自我纠错。
LLM Agent 的核心能力有哪些？
- 考察点：对 Agent 能力体系的掌握
- 参考回答思路：
  1. 任务理解与分解：将模糊指令拆解为可执行子任务
  2. 规划与推理：通过 CoT、ReAct 等机制实现多步推理
    - CoT（Chain of Thought）是让模型一步步写出推理过程，适合纯逻辑的任务。
    - ReAct（Reasoning + Acting）是边思考边行动，适合需要外部信息的任务。
  3. 工具调用：自主调用外部 API、数据库、代码解释器等扩展能力
  4. 记忆管理：维护短期 / 长期记忆，维持上下文一致性
  5. 自我反思与纠错：根据执行反馈修正错误路径
为什么说 LLM 是构建通用 Agent 的理想基座？
- 考察点：对 Agent 技术栈的底层理解
- 参考回答思路：
  - LLM 具备强泛化能力，跨领域的常识与语言理解能力
  - 支持零样本 / 少样本推理，无需重新训练即可适配新任务
  - 自然语言接口，能直接理解人类指令，生成可执行逻辑
  - 模块化扩展性，可通过 Function Calling 轻松集成外部工具
Agent 的自主性是什么意思？是不是完全不需要人类干预？
- 考察点：对 Agent 边界的认知
- 参考回答思路：
  - 自主性指 Agent 在给定边界内，能独立完成任务解析、工具选择、异常处理，无需人类分步指令。
  - 但自主性不等于完全脱离人类，而是在安全边界内最大化独立决策，高危操作仍需人工确认，同时支持人工在环干预。
Agent 必须是目标导向的吗？
- 考察点：对 Agent 本质属性的理解
- 参考回答思路：
  - 是的，目标导向是 Agent 的本质属性。没有目标的话，Agent 会退化为随机响应系统，无法衡量有效性。
  - 目标可以是显式的（用户指令），也可以是隐式的（系统预设，比如 “帮助用户解决问题”）。

产品岗基础题

你怎么向一个不懂技术的用户解释什么是 Agent？
- 考察点：技术认知与用户沟通能力
- 参考回答思路：可以用通俗的例子，比如传统工具是你要一步步指挥：“打开文件、复制文本、打开翻译、粘贴、导出 PDF、发我邮箱”；而 Agent 你只需要说一句 “把这份英文合同译好发我邮箱”，它会自己把所有步骤做完，全程不用你管，就像一个能帮你干活的智能助手。
Agent 和传统的 SaaS 软件有什么区别？
- 考察点：对产品形态的理解
- 参考回答思路：传统 SaaS （Software as a Service，软件即服务）是你操作工具，Agent 是工具帮你操作。比如传统的订票软件，你要自己查航班、选时间、填信息、支付；而 Agent 你只需要说 “帮我订下周五去上海的机票，要靠窗的，预算不超 1000”，它会自己帮你完成所有操作，还会根据你的偏好自动筛选。

二、核心技术与架构类面试题

（核心考察，占面试权重的 40% 以上）

推理与规划模块

什么是 ReAct 框架？它和 CoT（思维链）有什么区别？
- 考察点：对 Agent 核心推理框架的掌握
- 参考回答思路：
  - CoT 是让 LLM 一步步写出推理过程，只在模型内部思考，不调用外部工具，适合纯逻辑、不需要外部信息的任务（比如数学题）。
  - ReAct 是「Reasoning+Acting」，交替进行思考和行动，每一步思考后可以调用外部工具获取信息，再根据结果继续思考，适合需要外部信息、复杂交互的任务，比如搜索、工具调用。
  - 简单说：CoT 是 “想了再答”，ReAct 是 “边想边做”。
什么是 Tree of Thoughts（ToT）？它比 ReAct 强在哪？线上能用吗？
- 考察点：进阶规划技术的理解与落地能力
- 参考回答思路：
  - ToT 是把推理过程做成一棵多分支的树，模型可以同时探索多个推理路径，通过 BFS/DFS 探索最优路径，还能回溯无效分支，解决了 ReAct 只能单路径推理、错了就没法回头的问题。
  - 重度的 ToT 确实成本很高，线上不能全量用，但可以做轻量化版本：比如在关键场景，只生成 3-5 个候选路径，用轻量模型快速筛选，比如客服场景，同时生成 3 种不同的回复风格，快速选最优的，ROI （投资回报率）很高。
Plan-and-Execute 和 ReAct 的区别是什么？你会怎么选？
- 考察点：架构选型能力
- 参考回答思路：
  - Plan-and-Execute 是先生成完整的执行计划，再一步步执行，适合流程固定、不确定性低的任务，比如生成日报、固定流程的报表，能省成本，因为不用每一步都调用大模型思考。
  - ReAct 是边做边调整，适合不确定性高、用户可能随时改需求的开放任务，比如旅行规划，用户可能中途改目的地，ReAct 能随时调整。
  - 实践中我们会结合：Plan 做主干流程，每个步骤加 ReAct 的检查点，比如调用工具后自动检查结果，不对就立刻修复，兼顾效率和灵活性。
Agent 的任务分解有哪些策略？怎么避免分解得太碎或者太虚？
- 考察点：规划模块的落地经验
- 参考回答思路：
  - 常用的策略：分层分解，把大目标拆成高层子任务，再拆成可执行的原子任务；还有 LLM + 规则的混合方式，固定流程的用规则，开放任务用 LLM。
  - 避免问题的方法：一是给 LLM 加分解的示例，few-shot 教它怎么拆；二是加约束，比如子任务不能超过 5 步，每个子任务必须是可执行的原子操作；三是分解完之后做验证，让模型自己检查分解的任务是不是能覆盖原目标，有没有遗漏。
什么是 Agent 的反思（Reflection）机制？怎么实现？
- 考察点：Agent 自我迭代能力的理解
- 参考回答思路：
  - 反思机制就是 Agent 执行完任务后，自己评估结果，分析错误，然后修正策略，相当于自我纠错。
  - 实现方式：比如执行完工具调用后，让 LLM 评估结果是不是符合预期，如果不对，就分析哪里错了，调整参数或者换工具重试；还可以结合外部验证，比如代码写完了跑单元测试，根据测试结果反思修改。

记忆机制模块

Agent 的记忆分为哪几类？各自的作用是什么？
- 考察点：记忆系统的架构理解
- 参考回答思路：
  1. 短期记忆：存储当前会话的上下文，比如最近的对话轮次，维持当前任务的连贯性，存在上下文窗口里。
  2. 工作记忆：临时存储当前任务的中间状态，比如 ToT 的候选路径、任务进度，用来支撑当前任务的执行。
  3. 长期记忆：持久化存储历史交互、用户偏好、任务结果，用向量数据库存储，支持跨会话的知识复用，比如用户上次说的过敏信息，下次对话还能记住。
长对话里，怎么让 Agent 不忘记关键信息？怎么处理上下文窗口超限的问题？
- 考察点：记忆管理的落地经验
- 参考回答思路：我们用三段式记忆法，不是只靠向量检索：
  1. 滚动窗口记忆：最近 3-5 轮对话原样保留，保证当前任务的强相关信息不丢。
  2. 关键实体记忆：用 NER 实时提取用户提到的时间、地点、偏好这些关键实体，存到结构化的知识图谱里，随时能查，比如用户说的花生过敏，永远不会丢。
  3. 周期性摘要记忆：每 10 轮对话，让小模型生成一段结构化的摘要，记录用户的目标、任务进度、关键信息，代替原始的长对话。查询的时候把这三部分信息按权重融合，既不会丢关键信息，又不会把旧的闲聊信息带进来干扰。
向量数据库在 Agent 的记忆里起什么作用？怎么选向量数据库？
- 考察点：记忆存储的技术选型
- 参考回答思路：
  - 向量数据库用来存长期记忆的嵌入向量，支持语义检索，能把和当前问题相关的历史记忆找出来，注入到上下文里。
  - 选型的话：中小规模的用 Chroma、FAISS 就行，轻量好用；大规模的、需要分布式的用 Milvus、Pinecone，支持高并发、动态扩容；如果是私有化部署，Milvus 的开源版本很合适。
短期记忆和长期记忆怎么协同工作？
- 考察点：记忆系统的工作机制
- 参考回答思路：
  1. 每次用户请求过来，先从长期记忆里检索相关的历史信息，比如用户的偏好、历史任务。
  2. 把检索到的长期记忆，和当前的短期记忆（最近对话）拼接到一起，作为上下文传给 LLM。
  3. 任务完成后，把关键的新信息，比如用户的新偏好、任务结果，写入长期记忆，更新向量数据库。
  4. 优先级上，短期记忆的权重更高，避免过时的长期信息干扰当前任务。

工具调用模块

什么是 Function Calling？它在 Agent 里扮演什么角色？
- 考察点：工具调用的基础原理
- 参考回答思路：
  - Function Calling 是 LLM 的一种能力，能让模型根据用户的需求，输出结构化的函数调用格式，包括函数名和参数，这样系统就能解析这个格式，调用对应的外部工具，把结果返回给模型。
  - 它是 Agent 连接外部世界的接口，让 LLM 从只能生成文本，变成能调用 API、操作数据库、执行代码，真正拥有行动能力。
工具描述写得再好，模型也瞎传参数怎么办？
- 考察点：工具调用的落地痛点解决
- 参考回答思路：我们做了三层防护：
  1. Schema 层防护：不仅写清楚参数的要求，还要加负面描述，比如明确说 “城市名直接用用户输入的，不要自己从地址里解析”，还要加示例。
  2. 硬校验层：模型输出之后，用 Pydantic 模型做类型校验，比如参数类型不对、枚举值不匹配，直接打回去让模型重试。
  3. 业务兜底层：关键参数要做业务校验，比如订单 ID，先调用校验接口查是不是存在，没问题再往下执行，绝对不把未校验的参数直接发给数据库。
我们有上百个工具，怎么让模型快速选对工具？
- 考察点：大规模工具库的选型能力
- 参考回答思路：不能把所有工具都发给模型，上下文不够还会干扰判断，我们做了工具路由层：
  1. 用户请求过来，先用 fasttext 小模型快速提取意图关键词。
  2. 用关键词去工具的向量库做语义检索，挑出前 5 个最相关的工具。
  3. 再用一个精调过的 7B 小模型，给这 5 个工具做精细排序，最后只把前 2 个最相关的工具的 schema 发给大模型。这个流程把工具选择的准确率从 70% 提到了 95% 以上，还省了很多 token。
工具调用失败了怎么处理？比如接口超时、参数错误？
- 考察点：容错机制的设计
- 参考回答思路：我们有标准的错误分类处理流程：
  1. 如果是网络超时、5xx 错误，用指数退避重试，最多试 2 次。
  2. 如果是 4xx 参数错误，触发参数诊断，用小模型分析错误信息，调整参数后重试。
  3. 如果重试还是不行，而且这个工具是核心路径，就启动备选方案，比如主支付通道挂了，自动切备用通道。所有的状态都记日志，方便复盘，尽量能完成任务就不直接报错。
Function Calling 和 Tool Use 有什么区别？
- 考察点：工具调用的进阶理解
- 参考回答思路：
  - Function Calling 是标准化的，基于 JSON Schema，LLM 输出固定的 JSON 格式，实现简单，兼容 OpenAI 这类主流 API，但是灵活性差，不支持并行调用。
  - Tool Use 是更灵活的自定义格式，支持并行调用多个工具，支持工具依赖、复杂的组合调用，但是实现复杂度高，标准化程度低。
  - 简单场景用 Function Calling，复杂的工具系统用 Tool Use。
怎么实现工具的组合调用？有哪些模式？
- 考察点：复杂工具流程的设计
- 参考回答思路：常用的四种模式：
  1. 顺序调用：工具按顺序执行，后一个用前一个的结果，比如搜索→分析→生成报告。
  2. 并行调用：独立的工具同时执行，比如同时查天气、查航班、查酒店，提升效率。
  3. 条件调用：根据条件选工具，比如如果有票就订，没票就推荐中转。
  4. 循环调用：重复调用工具直到满足条件，比如批量处理订单。

主流框架与工具

你熟悉 LangChain 吗？它的核心组件有哪些？
- 考察点：主流开发框架的掌握
- 参考回答思路： LangChain 是 Agent 开发的框架，可以用于构建各种类型的 Agent，核心组件有：
  1. LLMs：大模型的封装，兼容各种主流模型。
  2. Tools：工具的抽象，支持各种外部工具的集成。
  3. Agents：Agent 的实现，比如 ReAct Agent、Plan-and-Execute Agent。
  4. Memory：记忆模块，支持各种记忆类型的实现。
  5. Chains：链的抽象，把多个操作串成流程。
  6. Vector Stores：向量数据库的封装，方便记忆存储。
LangGraph 和 LangChain 有什么区别？为什么需要图结构的 Agent？
- 考察点：框架的进阶理解
- 参考回答思路：
  - LangChain 是线性的链结构，适合顺序执行的流程，但是很难处理复杂的分支、循环、多 Agent 协作的场景。
  - LangGraph 是把 Agent 的流程做成有状态的图结构，支持循环、分支、持久化的状态，能处理多 Agent 协作、复杂的工作流，比如 MetaGPT 里的多角色协作，就是用 LangGraph 实现的。
  - 简单说，LangChain 做简单的单 Agent 流程，LangGraph 做复杂的多 Agent、带状态的工作流。
AutoGPT 和 BabyAGI 的主要区别是什么？
- 考察点：主流 Agent 产品的理解
- 参考回答思路：
  - AutoGPT 是通用的自主 Agent，目标是完成用户的开放任务，能自主规划、调用工具、反思，全流程自主执行，但是容易陷入循环，成本高。
  - BabyAGI 是基于任务优先级的 Agent，它会维护一个任务列表，每次选最高优先级的任务执行，执行完生成新的任务，更聚焦于任务的优先级管理，适合任务管理类的场景。
多智能体框架比如 MetaGPT、AutoGen，核心原理是什么？
- 考察点：多 Agent 框架的理解
- 参考回答思路：
  - MetaGPT 是把软件开发的流程引入多 Agent，给每个 Agent 分配不同的角色，比如产品经理、工程师、测试，模拟公司的协作流程，完成复杂的软件开发任务，它用标准化的通信协议，解决多 Agent 的沟通问题。
  - AutoGen 是支持多 Agent 的对话框架，能让不同的 Agent 之间对话，支持人工在环，能快速搭建多 Agent 协作系统，比如一个 Agent 写代码，一个 Agent 执行，一个 Agent 检查，适合快速原型。

三、RAG 与知识增强类面试题

（Agent 落地的核心模块，高频考察）

RAG 和 Agent 是什么关系？什么时候用 RAG，什么时候用 Agent？
- 考察点：技术选型能力
- 参考回答思路：
  - RAG 是检索增强生成，解决的是 LLM 的知识过时、幻觉的问题，它是一种知识增强的技术，很多 Agent 里都会集成 RAG，作为 Agent 的知识工具。
  - 如果只是问答、查资料，不需要复杂的任务执行，用 RAG 就够了；如果需要多步的任务执行、跨工具协同，比如查资料、分析、生成报告、发邮件，那就需要上 Agent，Agent 里可以用 RAG 来做知识增强。
RAG 的完整流程是什么？Chunk Size 怎么选？
- 考察点：RAG 的基础落地经验
- 参考回答思路：
  - 流程：文档加载→文本切片→嵌入生成→向量存储→检索→重排→生成。
  - Chunk Size 不是固定的，要看场景：如果是长文档、语义连贯的，比如论文，用 512-1024token；如果是短文本、问答类的，用 128-256；还要看嵌入模型的上下文，比如有的嵌入模型最大 512，那 chunk 就不能超过这个。还要做 overlap，比如重叠 20%，避免把完整的语义切开。
怎么解决 RAG 里检索不准、检索不到的问题？
- 考察点：RAG 的优化经验
- 参考回答思路：从几个层面优化：
  1. 切片优化：用语义切片，不是按固定长度切，而是按语义段落切，保证 chunk 的语义完整。
  2. 检索优化：用 Hybrid 检索，结合向量检索和关键词检索，解决向量检索漏关键词的问题；还要加重排，用 CrossEncoder 把检索到的结果重新排序，提升准确率。
  3. 查询优化：对用户的 query 做改写，比如把模糊的 query 改写成更适合检索的形式，或者加历史对话的信息，补全 query。
  4. 索引优化：用 GraphRAG，把文档做成知识图谱，解决长文档的关联信息检索的问题。
什么是 GraphRAG？它解决了什么问题？
- 考察点：进阶 RAG 技术的理解
- 参考回答思路：
  - 传统 RAG 是把文档切成独立的 chunk，检索的时候只能找单个 chunk 的信息，没法处理跨 chunk 的关联信息，比如问 “公司 2023 年的营收和 2022 年比增长了多少”，传统 RAG 可能只能找到 2023 的，找不到 2022 的，或者找不到关联的对比信息。
  - GraphRAG 是把文档里的实体、关系提取出来，做成知识图谱，检索的时候不仅查文本，还查实体的关联关系，能找到跨 chunk 的关联信息，适合处理复杂的、需要关联信息的问答，比如企业知识库、财报分析。
RAG 里怎么处理检索到的信息过多或者过少的问题？
- 考察点：RAG 的实战问题解决能力
- 参考回答思路：
  - 如果检索到的信息过多，模型可能会被干扰，解决方法是加重排机制，用一个小模型把检索到的结果重新排序，挑出最相关的前 3-5 个；还可以加摘要机制，把检索到的多个 chunk 摘要成一个更精炼的文本。
  - 如果检索到的信息过少，可能是 query 不够好，解决方法是对 query 做改写，比如加上历史对话的信息，或者用一个小模型把用户的 query 改写成更适合检索的形式；还可以放宽检索条件，比如增加 chunk 的数量，或者用更宽松的相似度阈值。
什么是知识图谱？它在 Agent 里有什么作用？
- 考察点：知识增强的技术理解
- 参考回答思路：
  - 知识图谱是把实体和它们之间的关系做成图结构的知识库，比如公司、产品、员工这些实体，以及它们之间的关系，比如 “Alice 是 Bob 的经理”。
  - 在 Agent 里，知识图谱可以作为长期记忆的一部分，支持复杂的查询和推理，比如用户问 “Alice 的经理是谁”，Agent 可以直接在知识图谱里查到；还可以支持复杂的关联查询，比如 “Bob 的同事有哪些”，通过关系链查到。

四、多智能体协作类面试题

（当前热点，高阶岗位必问）

什么是多智能体系统？它的优势是什么？适合什么场景？
- 考察点：多 Agent 的基础认知
- 参考回答思路：
  - 多智能体是多个不同的 Agent 一起协作完成任务，每个 Agent 有自己的专长和角色。
  - 优势：能处理单 Agent 搞不定的复杂任务，比如软件开发，单 Agent 很难同时做产品、开发、测试；能分工协作，每个 Agent 做自己擅长的事，提升效率；还能互相校验，减少错误。
  - 适合的场景：复杂的长任务，比如项目开发、内容创作、企业级的流程自动化，还有需要多角色协作的场景。
多智能体的协作模式有哪些？
- 考察点：多 Agent 的架构设计
- 参考回答思路：常用的模式：
  1. 主从模式：一个主 Agent 负责规划，分发给子 Agent 执行，比如 MetaGPT 里的协调者。
  2. 对等模式：所有 Agent 都是平等的，互相沟通协作，比如 AutoGen 里的多 Agent 对话。
  3. 流水线模式：Agent 按顺序处理，比如一个 Agent 做数据处理，一个做分析，一个做报告，流水线执行。
  4. 专家模式：不同的专家 Agent，处理不同的领域问题，用户的请求过来，路由给对应的专家 Agent。
多智能体协作的难点是什么？怎么解决？
- 考察点：多 Agent 的落地痛点
- 参考回答思路：难点和解决方法：
  1. 沟通效率：Agent 之间沟通容易鸡同鸭讲，解决方法是定义标准化的通信协议，比如统一的消息格式，让 Agent 之间能互相理解。
  2. 死锁和循环：A 等 B，B 等 A，卡住了，解决方法是加超时机制、循环检测，还有状态机管理，限制状态转移。
  3. 冲突解决：多个 Agent 的输出矛盾，解决方法是加仲裁 Agent，负责协调冲突，或者用投票机制。
  4. 责任归属：出错了不知道是谁的问题，解决方法是完整的日志，每个 Agent 的操作都记下来，方便溯源。
多 Agent 里怎么解决 Agent 之间的沟通问题？
- 考察点：多 Agent 的通信设计
- 参考回答思路：一是定义统一的通信语言，比如用结构化的消息格式，每个消息都有发送者、接收者、内容类型、时间戳，避免乱码；二是做共享的上下文池，所有 Agent 都能访问共享的状态和信息，避免信息不对称；三是加记忆机制，Agent 能记住之前的对话，不会重复问问题。

五、工程落地与性能优化类面试题

（大厂最看重的实战能力，字节 / 阿里高频真题）

怎么降低 Agent 系统的端到端延迟？
- 考察点：性能优化经验
- 参考回答思路：从几个层面优化：
  1. 模型选型：简单任务用小模型，比如意图识别、摘要，用 7B 的小模型，复杂任务用大模型，混合调度。
  2. 并行执行：独立的工具并行调用，不用串行等，比如同时查天气和航班，省时间。
  3. 流式输出：把中间结果流式返回给用户，不用等全部做完，提升体验。
  4. 缓存：热点的查询、工具结果做缓存，比如用户经常查的天气，缓存下来，不用重复调用。
  5. Prompt 优化：精简 prompt，去掉冗余的信息，减少 token，提升模型的响应速度。
怎么降低 Agent 的成本？
- 考察点：成本控制能力
- 参考回答思路：
  1. 缓存：相似的请求、工具结果缓存，避免重复调用大模型和 API。
  2. 模型分层：简单的任务用小模型，比如摘要、工具路由，用小模型，只有复杂的推理用大模型，大模型的调用成本降下来。
  3. Token 优化：压缩上下文，用摘要代替长对话，精简工具描述，减少 token 消耗。
  4. 批处理：批量处理任务，提升 GPU 的利用率，降低推理成本。
Agent 怎么处理模糊需求？比如用户说 “按老样子帮我订一下”？
- 考察点：用户体验的落地
- 参考回答思路：我们用 “先猜后问” 的策略：
  1. 先去查用户的历史订单，找出最近的、频次最高的、用户标记过的偏好订单，生成 1-3 个候选。
  2. 然后把候选抛给用户确认，比如 “你是想订上次那家 XX 酒店，还是上周的航班？”，不用让用户重新说一遍，也不会自己瞎猜直接执行。
怎么防止 Agent 无限循环、一直执行不停止？
- 考察点：流程控制的设计
- 参考回答思路：多层控制机制：
  1. 最大迭代次数：设置最大的执行轮数，到了就停止。
  2. 超时控制：任务最多执行 5 分钟，超时就终止。
  3. 循环检测：检测最近的执行是不是重复了，比如连续 3 次调用同一个工具，参数都一样，就判定是循环，停止。
  4. 目标检查：每一步都检查是不是已经达成目标了，达成了就立刻停止。
Agent 的幂等性是什么意思？为什么重要？
- 考察点：工程落地的基础认知
- 参考回答思路：幂等性就是同一个工具调用，执行一次和执行多次的结果是一样的，不会因为重试就产生副作用，比如重复支付。因为 Agent 的工具调用经常会重试，如果工具不是幂等的，重试就会出问题，比如用户订机票，重试了一次就买了两张票，所以工具必须设计成幂等的，或者加幂等令牌，保证重试不会出问题。
什么是Prompt Engineering？在 Agent 的落地中有哪些实用的技巧？
- 考察点：Prompt 优化的实战经验
- 参考回答思路：
  - Prompt Engineering 是设计和优化给 LLM 的输入提示，以引导模型生成更准确、相关的输出。
  - 实用技巧：
    1. 明确角色和任务：在 prompt 里明确告诉模型它是什么角色，要完成什么任务，比如 “你是我的智能助理，帮我订机票”。
    2. 提供示例：用 few-shot（少量示例）的方式给模型示例，告诉它正确的输入输出格式。
    3. 加约束：明确告诉模型不能做什么，比如 “不要自己编信息，所有数据都要通过工具获取”。
    4. 分步提示：把复杂的任务分成几个步骤，在 prompt 里一步步引导模型完成。
Agent 的 Prompt 和传统的 Prompt 有什么区别？
- 考察点：对 Agent 产品形态的理解
- 参考回答思路： Agent 的 Prompt 更复杂，不仅要包含任务描述，还要包含工具的描述、调用格式、错误处理机制、反思机制等，甚至还要包含多 Agent 协作的通信协议，而传统的 Prompt 可能只是简单的问答或者指令，Agent 的 Prompt 是一个完整的操作手册，指导模型如何在复杂的环境里完成任务。
Prompt Engineering、Context Engineering 和 Harness Engineering 之间有什么关系？
- 考察点：对 Agent 相关技术的整体理解
- 参考回答思路：
  - Prompt Engineering 是设计给 LLM 的输入提示，指导模型生成正确的输出。
  - Context Engineering 是设计和管理模型的上下文信息，包括记忆、工具描述、历史对话等，确保模型有足够的信息来完成任务。
  - Harness Engineering 是构建整个 Agent 系统的工程实践，包括模型调用、工具集成、流程控制、监控等，确保 Agent 能稳定、高效地运行。
  - 三者关系：Prompt Engineering 是 Context Engineering 的一部分，Context Engineering 是 Harness Engineering 的一部分，三者相辅相成，共同支撑 Agent 的落地。

六、安全、合规与风险控制类面试题

（企业落地的核心痛点，必问）

Agent 的安全性怎么保障？怎么防止 Prompt Injection？
- 考察点：安全防护的设计
- 参考回答思路：多层安全防护：
  1. 输入过滤：检测用户输入里的恶意注入内容，比如 “忽略之前的指令” 这类的，过滤掉。
  2. 沙箱隔离：代码执行、工具调用都放在沙箱里，隔离环境，不会影响主机。
  3. 权限控制：最小权限原则，Agent 的操作账号只有最小的权限，比如不能删库，不能改核心数据，高危操作必须要人工确认。
  4. 输出过滤：过滤输出里的敏感信息，防止泄露。
  5. 审计日志：所有的操作都记日志，出了问题能溯源。
如果 Agent 的决策出错了，比如误删了数据，系统怎么防范？
- 考察点：风险控制的落地
- 参考回答思路：核心是可审计、可回滚、最小权限：
  1. Dry-run 模式：所有的写操作、删除操作，先返回预览，让用户确认了再执行，不会直接就删。
  2. 操作分级：高危操作，比如删除、支付，不仅要用户确认，还要通知第二责任人，比如主管，双重确认。
  3. 可回滚：所有的修改操作都做备份，出错了能一键回滚。
  4. 完整日志：每个操作的完整过程，包括思维链、参数、结果，都记下来，能一键重现，定位问题。
Agent 的权限控制怎么做？
- 考察点：企业级安全的设计
- 参考回答思路：基于 RBAC 的权限控制：
  1. 给不同的用户、不同的 Agent 分配不同的角色，每个角色有不同的工具权限，比如普通用户的 Agent 不能调用财务的工具。
  2. 工具本身也有权限，比如查询订单的工具，只能查当前用户的订单，不能查别人的。
  3. 敏感操作的审批流，比如超过 1000 块的支付，需要上级审批。
Agent 可能有哪些伦理风险？怎么缓解？
- 考察点：合规与伦理的认知
- 参考回答思路：风险比如：生成有害内容、越权操作、数据泄露、偏见。缓解的方法：
  1. 对齐模型，用 RLHF、宪法 AI，让模型的输出符合伦理。
  2. 内容安全检测，输入输出都做安全过滤，防止有害内容。
  3. 数据脱敏，用户的敏感数据做脱敏，Agent 处理的时候看不到原始的敏感信息。
  4. 人工在环，高危操作必须人工确认，不能让 Agent 自己执行。

七、评估与可观测性类面试题

（生产落地的必备能力）

怎么评估一个 Agent 的好坏？有哪些指标？
- 考察点：评估体系的设计
- 参考回答思路：三维的评估指标：
  1. 效能维度：任务完成率、平均完成步数、平均耗时、Token 成本。
  2. 质量维度：结果准确率、工具调用准确率、用户满意度、一次解决率。
  3. 鲁棒性维度：异常处理成功率、自修复触发率、平均无故障运行时间。而且每次失败都要归因，是意图理解的问题，还是规划、工具、记忆的问题，驱动迭代。
Agent 的可观测性要做哪些？
- 考察点：生产监控的设计
- 参考回答思路：要监控几个部分：
  1. 执行日志：完整的执行轨迹，包括每一步的思考、工具调用、参数、结果，能复盘整个过程。
  2. 性能指标：响应时间、任务完成率、成本、错误率，做监控看板。
  3. 异常告警：比如错误率突增、成本突增、循环执行，立刻告警。
  4. 用户反馈：收集用户的反馈，比如结果对不对，有没有问题，用来迭代。
Agent 的幻觉怎么缓解？
- 考察点：质量控制的经验
- 参考回答思路：系统性的缓解：
  1. 工具调用的结果校验：所有的外部信息都来自工具，不让模型自己编，比如查天气，必须用 API 的结果，不能模型自己编。
  2. 事实核查：生成结果之后，用检索的信息做事实核查，看是不是有依据。
  3. 反思机制：让模型自己检查结果，有没有错误，有没有幻觉。
  4. 引用来源：生成结果的时候，带上信息的来源，用户能验证。

八、系统设计与场景题

（面试压轴题，考察架构设计能力）

请设计一个企业内部的知识库问答 Agent，你会怎么设计架构？
- 参考思路：架构分为几层：
  1. 接入层：用户的输入，支持文本、文件、多模态输入。
  2. 意图解析层：解析用户的问题，判断是问答还是任务。
  3. 记忆层：短期记忆存当前对话，长期记忆用向量数据库存用户的历史和知识库的向量。
  4. RAG 层：检索知识库的相关信息，做重排，给 LLM 做参考。
  5. Agent 层：如果是简单问答，直接生成；如果是复杂任务，比如查多个文档、分析数据，用 Agent 规划，调用不同的工具。
  6. 工具层：支持知识库检索、数据库查询、代码执行、内部系统的 API。
  7. 安全层：权限控制，不同的用户只能看自己有权限的文档，输入输出过滤，审计日志。
  8. 监控层：评估指标、日志、告警。
设计一个自动订票的 Agent，要考虑哪些问题？
- 参考思路：
  1. 需求解析：处理模糊需求，比如 “下周五去上海”，提取时间、地点、偏好，模糊的主动追问。
  2. 规划模块：分解任务：查航班→选航班→填信息→支付→发确认。
  3. 工具层：航班查询 API、用户信息查询、支付 API、邮件 API。
  4. 异常处理：没票怎么办？推荐中转或者改时间；支付失败怎么办？重试或者切通道。
  5. 记忆模块：存用户的偏好，比如靠窗、航空公司偏好，还有历史订单。
  6. 安全控制：支付必须用户确认，权限控制，只能订用户自己的票，日志审计。
  7. 状态管理：任务的状态，做到一半用户退出了，下次能恢复。
设计一个客服 Agent，怎么平衡自动化和人工介入？
- 参考思路：
  1. 意图识别：先判断问题的复杂度，简单的问题，比如查订单、改地址，Agent 自动处理。
  2. 置信度判断：如果 Agent 的回答置信度很低，比如低于 0.8，或者遇到解决不了的问题，自动转人工。
  3. 人工在环：高危操作，比如退款、改订单，Agent 生成方案，人工确认了再执行。
  4. 无缝切换：转人工的时候，把 Agent 的对话历史、处理进度都传给人工客服，不用用户重新说一遍。
  5. 反馈迭代：人工处理的问题，用来迭代 Agent 的模型，让 Agent 以后能自己处理。
设计一个支持百万级用户的 Agent 平台，架构怎么设计？
- 参考思路：
  1. 接入层：负载均衡，网关，处理用户的请求。
  2. 调度层：任务调度，把用户的任务分发给执行节点，做资源隔离。
  3. 模型层：模型服务，弹性扩缩容，支持不同的模型，小模型处理简单任务，大模型处理复杂的。
  4. 工具层：工具的注册、管理、路由，统一的工具调用网关，做鉴权、限流。
  5. 存储层：向量数据库集群，存长期记忆，关系数据库存状态、日志，缓存层存热点数据。
  6. 安全层：统一的权限控制、安全过滤、审计。
  7. 监控层：全链路的监控、告警、可观测性。
  8. 弹性扩缩容：根据流量自动扩缩容，应对峰值。

九、项目经验深挖类面试题

（面试官必问，考察真实落地能力）

讲一下你做过的 Agent 项目，核心目标是什么？你负责的模块是什么？
这个项目里最大的技术难点是什么？你是怎么解决的？
项目上线后的效果怎么样？用什么指标衡量的？
你在项目里做了哪些优化？带来了什么提升？
项目里遇到过什么线上问题？怎么排查和解决的？
如果让你重新做这个项目，你会优化哪些地方？
你做的 Agent 和市面上的同类产品比，有什么优势？

Agent on Snow

MCP 完全指南：原理、远程调用链路与自建服务接入 Agent

MCP 完全指南：原理、远程调用链路与自建服务接入 Agent

一、为什么需要 MCP

二、先认清四个角色

三、MCP 暴露什么

Tool 和普通 REST API 有什么不同

四、远程 MCP 的完整调用链路

1. 配置与发现

2. 工具进入模型上下文

3. 模型选择，Host 决策

4. HTTP 调用与业务执行

5. 结果回到模型

五、两种远程连接模式

六、从零开发一个远程 MCP Server

1. 初始化项目

2. 编写 server.py

3. 本地测试

4. 容器化与部署

七、让 Agent 真正使用你的 MCP

接入 Codex

接入 OpenAI Agents SDK

验证 Agent 是否会用

八、工具设计决定 Agent 上限

好工具的形状

MCP 不适合什么

九、安全：把模型、Server 和返回内容都当作不可信边界

十、可观测性与排错

十一、生产检查清单

结语

参考资料

Claude Code 和 Codex 的区别：从产品形态到工作流，一次讲透

Claude Code 和 Codex 的区别：从产品形态到工作流，一次讲透

先看总图

先把 Codex 这个词说清楚

一句话结论

差异总览

产品形态不同

工作流的默认假设不同

安全边界的设计重点不同

Claude Code 更像权限驱动

Codex 更像沙箱驱动

两种思路，分别适合谁

扩展能力的侧重点也不一样

Claude Code：更强调项目内沉淀

Codex：更强调平台化分发

团队协作体验也不同

到底怎么选

更适合选 Claude Code 的情况

更适合选 Codex 的情况

一个更真实的判断

总结

参考资料

关于 Agent 面试的那些事

前言

一、基础认知类面试题

技术岗基础题

产品岗基础题

二、核心技术与架构类面试题

推理与规划模块

记忆机制模块

工具调用模块

主流框架与工具

三、RAG 与知识增强类面试题

四、多智能体协作类面试题

五、工程落地与性能优化类面试题

六、安全、合规与风险控制类面试题

七、评估与可观测性类面试题

八、系统设计与场景题

九、项目经验深挖类面试题

2. 编写 `server.py`