从 Function Calling 到可运维系统：AI Agent 的架构分层与工程现实

2026 年的 AI Agent 技术叙事已经越过了“能不能调通一个工具”的阶段。IEEEE 的一篇结构性综述将现有 Agent 系统归纳为八种架构模式——单 Agent、工具增强、检索增强、反思式、多 Agent、层次式、黑板/共享记忆、人在回路——并提炼出九个反复出现的组件：感知、推理、规划、记忆、工具使用、行动执行、反思、协调、人类监督。组件清单本身并不新鲜，真正值得追问的是：这些组件以什么方式组织在一起，才能让一个“演示时惊艳”的系统在生产环境中“不 quietly 烂掉”。

一、架构分层的两条主线

当前工程实践中最清晰的一条分层线，是控制面与数据面的分离。Router–Worker 双层结构是这条主线的典型实现：Router 只负责接活、分类、分发、汇总，不深入执行；Worker 各自持有独立上下文，并行执行单一类型任务。DeepSeek 开源的 Super-agent 架构同样采用这一模式，Router 是持续运行的全局协调节点，Worker 在任务启动后订阅该任务的后续事件，不再让所有消息绕回调度层。

这条线之所以重要，是因为它解决的不是“模型够不够强”，而是上下文污染与状态管理。单个全能 Agent 承载所有任务时，不同任务的中间状态互相渗透，判断会被带偏；Router 一旦“顺手代做一点”，就会同时成为吞吐瓶颈和污染源。控制面轻量、数据面隔离，本质上是把经典分布式系统的关注点引入 Agent 设计。

另一条线是执行环境与状态存储的分离。执行循环运行在无状态容器中，会话与任务记录独立持久化，容器异常时重新调度并从持久状态恢复。一个常被忽视的判断是：Agent 的稳定性问题有很大一部分属于经典状态管理问题，而非模型能力问题。LangGraph 的 checkpointer 机制（builder.compile(checkpointer=checkpointer)）正是这一思路在框架层面的体现。

二、工具调用：两层协议，各司其职

工具调用是 Agent 从“生成文本”走向“改变系统状态”的关节。这里存在一个频繁被混淆的分层：Function Calling 是模型侧的表达机制，MCP 是系统侧的连接协议。

Function Calling（Tool Calling）的本质是模型与应用程序之间的一次结构化往返：开发者用 JSON Schema 描述工具，模型判断是否需要调用、返回 tool_calls（函数名加参数 JSON），应用程序负责校验、执行、回填结果。关键边界在于：模型只表达调用意图，不执行任何函数。这个边界如果不清晰，调试工具调用问题时会陷入“以为是模型乱调，实际是应用层校验缺失”的误区。

MCP（Model Context Protocol）解决的则是另一个层次的问题。它以 JSON-RPC 2.0 为基础，采用 Host–Client–Server 三层模型，将外部能力标准化为Resources、Tools、Prompts三种基元。MCP 的价值不在于替代 Function Calling，而在于把“每一种模型连接每一种外部资源”的 N×M 集成问题简化为 N+M 的线性模式。二者是机制与协议的分层关系：Function Calling 负责“模型怎么说要调什么”，MCP 负责“工具怎么被安全地暴露和发现”。

工具定义的质量直接决定调用可靠性。一个工具如果描述模糊、参数 Schema 过宽、读写操作混在同一个命名空间，模型的选择准确率会显著下降。生产中的常见对策是查询类与执行类工具物理分开，并对参数做严格校验。

三、编排框架：隐喻匹配比功能清单更重要

2026 年主流 Python 编排框架已经形成四种清晰的调度隐喻：LangGraph 的图结构显式编排、CrewAI 的角色流、AutoGen 的对话流、LlamaIndex Workflows 的事件驱动。框架选型的第一原则不是比较功能列表，而是任务结构与框架隐喻是否匹配。

对于确定性流水线（如代码审查→安全扫描→合规检查→汇总报告），LangGraph 是正选：流程显式、调试时看图即知执行路径。如果错误地用 AutoGen 的对话流去承载这类任务，每一步都要变成 Agent 之间的消息传递，而对话语义天然允许分叉，团队需要不断加约束防止 Agent 偏离流程，最终框架成为负担。反过来，开放式探索和方案辩论适合对话流，用图框架去写自由探索则会造成过度约束。

成本维度同样不可忽视。多 Agent 编排层在生产中可占总推理成本的 15%–40%，而缺少难度路由的朴素编排在简单任务上可能消耗 3–5 倍的必要 Token。LangGraph 在结构化工作流中的 Token 效率相对最优，因为控制流由图的边显式编码，框架不需要生成“下一步做什么”的自由推理；AutoGen 的对话架构则因每个 Agent 看到完整会话历史，在高频生产中可能带来 20%–40% 的额外推理成本。

下面是一个 LangGraph 状态图的骨架，展示工具绑定与持久化检查点的最小可用结构：

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.memory import InMemorySaver
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]

@tool
def search_docs(query: str) -> str:
    """在企业文档库中检索与查询相关的片段。"""
    return f"docs for: {query}"

llm = ChatOpenAI(model="gpt-4o-mini").bind_tools([search_docs])

def call_model(state: AgentState):
    return {"messages": [llm.invoke(state["messages"])]}

def should_continue(state: AgentState):
    last = state["messages"][-1]
    return "tools" if getattr(last, "tool_calls", None) else END

builder = StateGraph(AgentState)
builder.add_node("agent", call_model)
builder.add_node("tools", lambda s: {"messages": []})  # 实际执行工具并回填 ToolMessage
builder.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
builder.add_edge("tools", "agent")

checkpointer = InMemorySaver()
graph = builder.compile(checkpointer=checkpointer)

checkpointer 使得图的每一步状态都被持久化，异常后可以从最近检查点恢复，而不是从零重来。生产环境中可将 InMemorySaver 替换为 PostgresSaver。这个骨架的价值不在代码量，而在于它把“条件分支、循环、状态恢复”做成了框架的一等公民，而不是每次有新需求时重新发明。

四、从 Demo 到生产：四道坎与具体数据

工具调用的可靠性是第一道坎，也是落差最大的一道。一组覆盖约 12000 次真实任务执行的统计给出了直观的数字：Demo 环境工具调用成功率 96%，生产环境降至 71%；任务端到端完成率从 92% 降至 58%；单任务 Token 成本超预算 3–8 倍；事后可追溯性在 Demo 中无需考虑，在生产中则沦为“不知道它当时干了啥”。

这些差距的根因不在模型能力，而在模型外面那层工程壳。Agent 开发中反复出现的三大故障——死循环、误调用、权限越界——各有对应的兜底手段：设置最大步数强制收尾；查询类与执行类工具物理分开并对参数做 Schema 校验；高风险动作拆出并要求人工确认。这些手段本身并不复杂，难的是把它们作为默认架构的一部分而非事后补丁。

第二道坎是权限与可逆性分级。按“可逆性”与“影响范围”两个维度授权：L1 只读、L2 出草稿、L3 可逆执行、L4 将 L3 沉淀为规则但依赖审计；涉及资金与对外发言的两类权限必须延迟授予。这套分级的实质是把 Agent 的能力释放控制在“出错可以回退”的范围内。

第三道坎是上下文预算。长时间自主执行中，上下文压缩应当被设计为常规路径而非异常降级。参考做法是将上下文控制在二十万 Token 量级，超过十万且用户离开一段时间后触发压缩，把前段历史抽象为摘要继续执行；同时保持提示词模板稳定，利用前缀缓存降低后台常驻型 Agent 的账单成本。

第四道坎是评测与可观测性。Agent 评测不能只看终态答案是否“正确”：两个 Agent 终态都对，一个靠稳定路径收敛，一个靠搜索空间暴力采样命中，在结果层不可区分，在轨迹层天差地别。因此评测需要从 Result 下钻到 Trajectory（路径是否收敛可复现）、Efficiency（延迟、Token、步数）、Risk（越权、泄露，一票否决）。Trace 应当先于评测：一次执行链路至少记录 Prompt 模板、工具调用决策、返回结果、Token 消耗和中间状态，日志格式兼容 OpenTelemetry，把 Trace 作为上线硬前提而非事后补课。

结语

Agent 工程化没有单一的银弹。换更强的模型、写更长的提示词、画更复杂的流程图，每一次“这一下应该够了”的期待，最终都指向同一组问题：控制面是否足够轻、数据面是否足够隔离、工具调用的语义边界是否清晰、状态是否可恢复、失败是否可追溯。模型决定上限，工程决定下限——而在绝大多数真实业务场景里，决定系统能否被持续使用的，恰恰是下限。把 Agent 当作一个需要运维的分布式系统来设计，而不是一个更聪明的聊天接口，可能是从 Demo 走向生产最朴素也最关键的一步。