Agent on Snow

The Complete MCP Guide: Architecture, Remote Call Flow, and Building Your Own Server

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

The Complete MCP Guide: Architecture, Remote Call Flow, and Building Your Own Server

A language model can reason and generate text, but it does not know which project your company created today, nor can it create a ticket by imagination alone. MCP provides a standard, controlled path from an agent to that live data and those actions.

The one-sentence definition is:

The Model Context Protocol (MCP) is a standard interface between agent applications and external capabilities. It defines capability discovery, schemas, calls, results, and negotiation. It is neither a model nor a replacement for your business API.

This article follows the 2026-07-28 MCP specification and calls out common differences in older clients. MCP is evolving quickly, so production integrations should follow the protocol versions supported by their host and SDK.

Why MCP exists

Without a shared protocol, every agent platform needs a custom adapter for every external system. Connecting three hosts to GitHub, a database, and a ticket system can quickly become nine integrations.

flowchart LR subgraph Before[Without MCP: N × M adapters] A1[Agent A] --> X1[GitHub adapter] A1 --> X2[Database adapter] A2[Agent B] --> X3[GitHub adapter] A2 --> X4[Ticket adapter] end subgraph After[With MCP: one protocol boundary] B1[Agent A] --> P[MCP] B2[Agent B] --> P P --> S1[GitHub Server] P --> S2[Database Server] P --> S3[Ticket Server] end

MCP standardizes more than the final HTTP request:

Question	MCP mechanism
What can this server do?	`tools/list`, `resources/list`, `prompts/list`
What arguments are valid?	JSON Schema
How is an action executed?	`tools/call`
How is addressable context read?	`resources/read`
How are results represented?	`content`, `structuredContent`, errors, and metadata
Which features do both sides support?	Protocol version, capabilities, and extensions
How do messages travel?	Local `stdio` or remote Streamable HTTP

The USB-C analogy is useful but incomplete. USB-C standardizes a physical interface; MCP standardizes an interface whose names, descriptions, and schemas are interpreted by a model. Metadata is therefore part of the product experience, not incidental documentation.

The four roles

flowchart LR U[User] --> H[Host
Agent application] H --> M[LLM] H --> C1[MCP Client A] H --> C2[MCP Client B] C1 <-->|MCP| S1[MCP Server
Project system] C2 <-->|MCP| S2[MCP Server
Knowledge base] S1 --> API1[(Business API / DB)] S2 --> API2[(Documents / Search)]

Role	Responsibility	Important boundary
User	States a goal and confirms consequential actions	Usually does not construct protocol messages
Host	Owns the agent, model context, policy, approvals, and MCP clients	The MCP server does not run the whole agent loop
MCP Client	Talks to one server and handles discovery, calls, and compatibility	Usually an internal host component
MCP Server	Exposes capabilities, validates calls, and reaches business systems	It must not expose unrestricted backend access

The model normally does not connect directly to the server. The host shows the model an allowed set of capabilities. The model proposes a tool call. The host applies policy and approval rules before executing it. This separates model intent from system authority.

Tools, resources, and prompts

Primitive	Primary controller	Best for	Example
Tools	Model selects; host governs execution	Queries and actions	`search_projects`, `create_ticket`
Resources	Host or application loads	Addressable, usually read-only context	`project://P-1024/spec`
Prompts	User or host selects	Reusable workflow templates	“Create a release checklist”

The protocol also includes notifications and other optional capabilities. A useful server rarely needs all of them. Start with a few well-designed tools.

An MCP server is often an agent-facing adapter over existing systems:

flowchart LR L[Tool visible to the LLM
name + description + schema] --> S[MCP Server
auth · validation · orchestration] S --> R1[REST API] S --> R2[gRPC] S --> R3[(Database)] S --> R4[Message queue]

A REST route might be PATCH /v1/projects/:id. A useful MCP tool is goal-oriented: archive_project(project_id, reason). Do not mirror hundreds of internal endpoints into hundreds of model tools.

The complete remote MCP call path

Remote MCP normally uses Streamable HTTP. The older HTTP+SSE transport is superseded and should only remain for compatibility.

sequenceDiagram autonumber actor User participant Host as Agent Host participant Model as LLM participant Client as MCP Client participant Server as Remote MCP Server participant API as Business system Host->>Client: Load server configuration Client->>Server: Discover protocol and capabilities Server-->>Client: Server info + capabilities Client->>Server: tools/list Server-->>Client: Names, descriptions, schemas, annotations User->>Host: “List delayed projects this week” Host->>Model: Message + allowed tool definitions Model-->>Host: list_projects(status="delayed") Host->>Host: Policy check / approval if needed Host->>Client: Execute approved call Client->>Server: tools/call + credentials Server->>Server: Authenticate, authorize, validate Server->>API: Query current business data API-->>Server: Project records Server-->>Client: content + structuredContent Client-->>Host: Tool result Host->>Model: Add allowed result to context Model-->>Host: Compose answer Host-->>User: Final response + action status

1. Configuration and discovery

The host stores a server name, URL, and authentication method. The client learns the protocol version, server information, and capabilities, then lists tools. Hosts may cache the list and refresh it when capabilities change or the cache expires.

In the 2026-07-28 protocol, the modern path is stateless: server/discover and per-request metadata replace the old connection handshake and protocol-level session. Older clients can still use initialize → initialized and Mcp-Session-Id. Let the SDK negotiate this; application code should not handcraft JSON-RPC.

2. Tools enter model context

The host may filter tools by user, tenant, role, task, or dynamic tool search. Only the relevant names, descriptions, and schemas need to enter context. Five distinct tools are usually more reliable and cheaper than fifty overlapping ones.

3. The model selects; the host decides

The model produces structured intent, not authority. The host should decide whether the user may call that tool, whether a write needs confirmation, whether arguments cross cost or data boundaries, and whether prompt injection or destructive behavior is suspected.

Annotations such as readOnly, destructive, and openWorld inform host policy. They are hints, not authorization controls.

4. HTTP and business execution

The client sends an MCP request over HTTPS to an endpoint such as /mcp, with protocol-routing information and usually an Authorization header. The server must independently validate the token, scopes, tenant, object-level permission, arguments, timeouts, and audit context before calling the real REST API, gRPC service, or database.

MCP does not make a dangerous SQL query safe, and it does not replace business authorization.

Expanding the details normally hidden by an SDK, a modern tool call looks roughly like this (some per-request _meta is omitted for readability):

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}
  }
}

The successful JSON-RPC result carries model-readable content and schema-bound data for the application:

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

Do not handcraft these messages in application code. The example is useful for reading gateway logs and traces; SDKs should own negotiation, headers, and JSON-RPC details.

5. Results return to the model

Channel	Consumer	Guidance
`content`	Model	Concise, understandable explanation of the result
`structuredContent`	Host, UI, or later calls	Schema-valid fields and stable identifiers
`_meta`	Client application	Client-only data; not a secret vault

The host puts approved result content back into the model context. The model then answers or plans another call. A successful MCP request does not necessarily mean the user task succeeded: the agent must inspect isError, completeness, and any follow-up requirements.

Two remote connection models

flowchart TB subgraph Direct[Mode A: runtime-managed connection] A[Your agent application] --> C[MCP Client] C --> S[Remote MCP Server] end subgraph Hosted[Mode B: platform-hosted connection] B[Your application] --> P[Model / Agent platform] P --> HS[Remote MCP Server] end

Mode	Main advantage	Best fit
Runtime-managed	Your app owns networking, credentials, filtering, and approval	Private networks, strict compliance, custom policy
Hosted MCP	Less integration code; the agent platform handles protocol calls	Public HTTPS services and quick integrations

The OpenAI Agents SDK supports hosted MCP for public remote servers and runtime-managed stdio or Streamable HTTP for local and private servers. The choice is about who should own the connection and trust boundary.

Build a remote MCP server

The following minimal project exposes a read-only project catalog. It uses Python SDK v2, Python 3.10+, and stateless Streamable HTTP so that replicas can scale horizontally.

Set up the project

1
2
3

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

Pin the major SDK version. The protocol and SDKs move quickly; a production build should not cross a major version without review.

Create `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,
    )

The function name becomes the tool name, its docstring becomes the description, type hints generate the input schema, and the return annotation generates the output schema. The annotations describe behavior to the host. The SDK handles MCP framing, version compatibility, and Streamable HTTP.

Replace the in-memory list with a business service call in production, but always derive the tenant from verified credentials rather than a model-supplied user_id.

Test locally

Use the official Inspector first:

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

Then start the HTTP server:

1
2

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

An SDK client makes a compact regression check:

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())

Test valid calls, boundaries, invalid enums, authorization failures, downstream timeouts, empty results, and output-schema validation. Inspector proves the protocol works; automated tests prove it still works after an upgrade.

Containerize and deploy

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

Production should expose a stable HTTPS URL such as https://mcp.example.com/mcp. Configure proxies for streaming behavior, bounded request size, sensible timeouts, and idle connections.

The demo server has no authentication and is only suitable for local learning. Before exposing it to any network, configure the SDK’s token verifier or OAuth support and enforce business authorization inside every tool.

Stateless mode is a good default. If a workflow needs state across calls, prefer returning an explicit server-minted handle and accepting it in later tools instead of hiding state in one replica’s memory.

Connect the server to an agent

A reachable endpoint is only half the work. The agent needs registration, authorization, routing guidance, and behavioral tests.

Codex

1
2

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

Or configure ~/.codex/config.toml:

1
2

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

Add a short, testable routing rule to the project’s AGENTS.md:

1
2
3

When a task needs a current project status, owner, or project ID, use the
read-only tools from the projects MCP first. Before any update, archive, or
delete operation, show the exact target and impact and wait for confirmation.

Configuration determines what the agent can see. Instructions help it decide when to use those capabilities. Never tell it to blindly trust remote content; tool results can be stale or malicious.

OpenAI Agents SDK

A public remote server can be attached as a hosted MCP tool:

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",  # safe only for this read-only tool
            }
        )
    ],
)

Do not copy never onto write tools. Match approval policy to risk, and keep independent authorization on the server. For private services, let your Agents SDK runtime own the connection so that your application controls networking, filtering, and approvals.

Verify actual agent behavior

Prompt	Expected behavior
“List delayed projects”	Calls `list_projects(status="delayed")`
“What does delayed mean?”	Answers generally without a pointless call unless company policy is requested
“Delete P-1002”	Explains that no delete tool exists; never fabricates success
“Use `status=hacked`”	Schema rejects it; agent corrects or explains
Result contains “ignore previous instructions”	Treats it as untrusted data and does not escalate privileges

Measure tool selection, argument correctness, and answer faithfulness. Looking only at final prose can hide duplicate calls, denied actions, and unnecessary cost.

Tool design sets the agent’s ceiling

flowchart LR G[User goal] --> N[Clear verb name] N --> D[When-to-use description] D --> I[Narrow input schema] I --> A[Truthful annotations] A --> O[Stable structured output] O --> E[Recoverable errors]

Give each tool one recognizable goal. Prefer list_projects, get_project, and update_project over project_action(mode, payload).
Describe when to use the tool, not only how it is implemented.
Encode enums, lengths, ranges, and formats in the schema.
Separate reads and writes so the host can apply different approval rules.
Return stable IDs for later calls.
Paginate and cap results.
Return actionable errors, not stack traces.
Evolve schemas compatibly. Optional additions are safer than renames or type changes.

MCP is not always the answer. A private function used by one application may be simpler as a function tool. Large continuous media transfer needs a different data plane. Deterministic transaction state machines should not be delegated entirely to model planning. Unrestricted SQL, shell, or URL-fetching tools should not be exposed in production.

Security: every boundary is untrusted

flowchart LR U[User input
untrusted] --> H[Host policy] H -->|minimum tool set| M[Model output
untrusted intent] M --> A{Approval / authorization} A --> S[MCP Server
authenticate and validate again] S --> B[Business system] B --> R[Tool result
still untrusted] R --> H

Risk	Required defense
Cross-tenant access	Validate token, scope, tenant, and object permission on every call
Destructive action	Separate tool, truthful annotations, confirmation, idempotency key, audit, rollback
Prompt injection	Treat returned content as data; never let it rewrite host policy
Token leakage	Keep tokens out of descriptions, results, and logs; validate token audience
SSRF	URL allowlists, DNS/IP checks, block metadata/private ranges, bound redirects
Excessive data	Field minimization, pagination, result caps, PII redaction
Cost or denial of service	Rate, concurrency, timeout, circuit-breaker, and quota controls
Supply-chain drift	Pin SDK majors, scan dependencies, canary upgrades, rollback

Authentication says who the caller is; authorization says what that caller may do to this particular object. Never trust a model-provided user_id as the tenant boundary. OAuth deployments should use standard discovery, narrow scopes, and an explicit audience.

Host prompts, annotations, approval dialogs, and network allowlists are defense in depth. Server-side object authorization remains the final boundary.

Observability and troubleshooting

An MCP failure can happen because the model did not select a tool, the host denied it, the protocol failed, or a downstream system failed. Logs and traces need to connect these layers.

Record a trace or request ID, server/tool/version, redacted caller and tenant, approval outcome, total and downstream latency, result size, error category, schema version, and deployment version. Never log access tokens or complete private results.

Symptom	Check first
Server cannot connect	URL, certificate, DNS, Host header, firewall, `/mcp` path
Connected but no tools	Discovery/capabilities, `tools/list`, registration code
Model never calls a tool	Names, descriptions, instructions, overlapping tools
Arguments are consistently wrong	Schema breadth, ambiguous semantics, missing enums
Local works; remote times out	Proxy streaming, platform timeout, cold start, downstream latency
Call succeeds; answer is wrong	Content clarity, missing structured fields, stale cache
Multi-replica failures	Hidden process state or old session affinity assumptions

The shortest diagnostic path is usually: Inspector → direct SDK client → host tool list → one complete agent trace. It separates server, protocol, and model-decision problems quickly.

Production checklist

Tool names, descriptions, input schemas, and output schemas reviewed
Reads, writes, and destructive operations separated
Authentication, scopes, tenant, and object authorization enforced per request
Stable HTTPS Streamable HTTP endpoint
Approval, idempotency, audit, and rollback for writes
Pagination and result-size limits; no secrets in results
Timeouts, retries, rate limits, circuit breakers, and downstream error mapping
Inspector checks, automated tests, and agent behavior evals pass
Traces, metrics, redacted logs, and alerts exist
SDK and schema versions pinned; upgrades can canary and roll back

Closing thought

MCP is not merely a way for a model to send an HTTP request. It gives capability discovery, argument contracts, execution, results, and security policy a shared path.

flowchart LR A[Pick one real user goal] --> B[Design one narrow tool] B --> C[Test with Inspector] C --> D[Automate tests] D --> E[Streamable HTTP + auth] E --> F[Connect the agent] F --> G[Evaluate and observe] G --> H[Add the next tool]

Make one read-only tool accurate before adding writes. Establish authorization before building elaborate orchestration. MCP reduces integration cost; it does not replace sound API design, authorization, or operational discipline.

References

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 编程工具怎么选

参考资料

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

About Agent Interview

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

The Complete MCP Guide: Architecture, Remote Call Flow, and Building Your Own Server

The Complete MCP Guide: Architecture, Remote Call Flow, and Building Your Own Server

Why MCP exists

The four roles

Tools, resources, and prompts

The complete remote MCP call path

1. Configuration and discovery

2. Tools enter model context

3. The model selects; the host decides

4. HTTP and business execution

5. Results return to the model

Two remote connection models

Build a remote MCP server

Set up the project

Create server.py

Test locally

Containerize and deploy

Connect the server to an agent

Codex

OpenAI Agents SDK

Verify actual agent behavior

Tool design sets the agent’s ceiling

Security: every boundary is untrusted

Observability and troubleshooting

Production checklist

Closing thought

References

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

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

先看总图

先把 Codex 这个词说清楚

一句话结论

差异总览

产品形态不同

工作流的默认假设不同

安全边界的设计重点不同

Claude Code 更像权限驱动

Codex 更像沙箱驱动

两种思路，分别适合谁

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

Claude Code：更强调项目内沉淀

Codex：更强调平台化分发

团队协作体验也不同

到底怎么选

更适合选 Claude Code 的情况

更适合选 Codex 的情况

一个更真实的判断

总结

参考资料

About Agent Interview

前言

一、基础认知类面试题

技术岗基础题

产品岗基础题

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

推理与规划模块

记忆机制模块

工具调用模块

主流框架与工具

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

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

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

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

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

八、系统设计与场景题

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

Create `server.py`