2026-04-22 · architecture / ai-infra
【大模型基础设施工程】01:大模型基础设施全景 —— 训练、推理、RAG、Agent、观测
面向工程师的大模型基础设施开篇地图,覆盖 2022 到 2026 的工程分水岭、五层工程栈、训练与推理的工程差异、中国与全球行业版图以及成本曲线。


























本文是【大模型基础设施工程】系列的第 19 篇。RAG 解决了”让模型知道”,Agent 解决的是”让模型会做”:从一句话自然语言需求出发,规划步骤、调用工具、观察结果、纠错重试,直到任务完成。本篇不做”agent 能改变世界”式的宏大叙事,只谈工程栈——抽象、框架、协议、沙箱、评测——以及在落地时真实踩过的坑。
Agent 并不是 2024 年才出现的概念,但 LLM 让它第一次工程可行。把过去几年的关键节点串起来看:
| 年份 | 范式 | 代表作 | 核心想法 |
|---|---|---|---|
| 2022.10 | ReAct | Yao 等,Princeton/Google | Reasoning + Acting 交错,推理和工具调用在同一个提示里 |
| 2023.03 | Plan-and-Execute | BabyAGI、LangChain PlanAndExecute | 先整体规划再逐步执行,降低短视 |
| 2023.03 | AutoGPT | Significant-Gravitas | 自驱动循环、写入长期记忆、文件系统操作 |
| 2023.05 | Reflexion | Shinn 等,Noah | 失败后写反思,写入 episodic memory |
| 2023.06 | Function calling | OpenAI | 将”工具”从 prompt 里拆出来,进入 API 一等公民 |
| 2023.10 | AutoGen | 微软 | 多 agent 对话(Conversable Agent) |
| 2024.01 | CrewAI | João Moura | 角色扮演 + 团队协作 |
| 2024.03 | LangGraph | LangChain | 图式状态机,取代传统 AgentExecutor |
| 2024.10 | Computer Use | Anthropic | 像素级屏幕操作 |
| 2024.11 | MCP | Anthropic | 工具 / 资源的标准协议 |
| 2025.01 | OpenAI Operator / Agents SDK | OpenAI | 官方下场 |
| 2025.04 | A2A | Agent 间互操作协议 | |
| 2025 起 | Agentic Reasoning | o1、DeepSeek-R1、Claude 3.7 Thinking | 推理过程本身就包含规划、反思、工具调用 |
ReAct 的核心在于把思考(Thought)和行动(Action)写在一个 prompt 循环里:
Thought: 我需要查询北京今天的 PM2.5
Action: search[北京 PM2.5 今天]
Observation: 今日北京 PM2.5 约 48,良
Thought: 已获取,可以回答
Action: finish[北京今天 PM2.5 大约 48]
这种格式有三个工程优势:
Action
后面停下,由外部执行器去跑工具,结果注入
Observation。Thought/Action/Observation 序列。2023 年 OpenAI Function Calling 发布后,ReAct 的文本解析逐渐被结构化 tool_call取代,但循环本质未变。
ReAct 的缺点是短视:每一步都靠上一步的局部推理,面对多跳任务容易绕圈。Plan-and-Execute 先让 LLM 输出一个 JSON 计划,再按计划调度每一步;Reflexion 则在失败后插入一个”自我反思”步骤,把反思写入 episodic memory,下一次轮次读回来。
这两个思路如今已融进主流框架:LangGraph 里的
plan → execute → replan 子图、AutoGen 的
GroupChatManager、CrewAI 的
Process.hierarchical,本质都是 Plan-and-Execute
的变体。
2024 年底开始,o1、DeepSeek-R1、Claude 3.7 Thinking
把长链推理内化到模型本身——模型在回答前会生成几千到几万
token 的 <thinking>
块,里面就包含”规划—执行—反思”的完整循环。
这带来一个结构性变化:框架层需要做的规划编排变少了。很多在 GPT-4 时代必须用 LangGraph 显式展开的子图,在 R1/o1 上直接一次调用就能完成。这意味着:
不同框架叫法各异,但跑不出这五个核心对象:
短期记忆就是多轮对话上下文,工程上有几种做法:
ConversationSummaryMemory)。长期记忆则更分化:
| 类型 | 存储 | 代表 | 适用 |
|---|---|---|---|
| Vector memory | 向量库 | Mem0、Letta | 语义相似检索 |
| Episodic memory | 结构化 JSON | Reflexion、MemGPT | “上次我做 X 失败了,原因是 Y” |
| Knowledge graph memory | 图库 | Zep、Graphiti | 实体关系、时序演化 |
| Document memory | 文件系统 | AutoGPT、Claude Code | 大段文本,按路径访问 |
| Procedural memory | 代码 | voyager skill library | “我学会的技能” 的代码片段 |
工程上不必只选一种,生产级 agent 往往短期用摘要、长期用向量 + 图混合。
传统 AgentExecutor 是一个 while 循环,控制流写死在代码里。问题是:
LangGraph、Pydantic Graph、OpenAI Agents SDK 的 handoff
等新一代框架统一改用显式状态图。节点是纯函数
state -> state,边是条件路由函数
state -> node_name,状态是一个 Pydantic /
TypedDict,持久化到
checkpointer(内存、SQLite、Redis、Postgres 都行)。
这一套抽象的直接好处:持久化、回放、时间旅行、人工介入几乎免费获得。
LangChain 是 2022 年底最早一批 LLM 框架,覆盖 Chain、Retriever、Agent、Tool、OutputParser 全套原语。2024 年后官方把 agent 部分独立为 LangGraph,核心抽象从 AgentExecutor 变为 StateGraph + Checkpointer。
选型建议:
从 RAG 起家,Agent 是在 RAG
之上扩展的:ReActAgent、FunctionCallingAgent、AgentWorkflow。它的强项是数据层——超过
300 个 data loader 与超强的 document/node 抽象。
选型建议:
QueryEngineTool + AgentWorkflow
组合很顺手。AutoGen 把 agent
建模为可对话的实体:任何 agent 都有
send() 和 receive(),多 agent
之间靠发消息协作。典型模式:
UserProxyAgent(代表人类,也可自动回复)AssistantAgent(LLM)GroupChatManager(调度员)2024 下半年的 AutoGen 0.4 大重构为 actor
model,引入异步消息总线,更接近分布式系统的编程模型。微软自家的
Magentic-One 就建立在上面。
CrewAI 把 agent 拟人化:每个 Agent 有
role、goal、backstory;任务用
Task 对象;多个 agent 组成
Crew,支持 sequential 和
hierarchical 两种流程。
from crewai import Agent, Task, Crew
researcher = Agent(role="研究员", goal="找齐最新论文", backstory="...")
writer = Agent(role="写作者", goal="产出博文", backstory="...")
crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
crew.kickoff()优点是心智模型直观,做 demo 快;缺点是黑盒偏多、生产级可观测性弱、底层仍基于 LangChain。
DSPy 的路线完全不同:它把 prompt
当成可训练参数。你声明
Signature(输入输出类型 + 描述),框架自动生成
prompt,然后用训练集 + metric 去优化 few-shot
和指令。
class GenerateAnswer(dspy.Signature):
"""Answer questions with short factoid answers."""
context = dspy.InputField()
question = dspy.InputField()
answer = dspy.OutputField()适合有评测集、想把 prompt 工程自动化的团队。DSPy 也支持 ReAct 和 tool use,但重点始终是”编译 prompt”。
Pydantic AI 是 Pydantic 作者 Samuel Colvin 2024
年推出的框架,卖点是类型安全。tool 就是
@agent.tool 装饰器,输入输出是 Pydantic
model,结构化输出直接走 result_type。对 Python
生态重度用户非常友好。
OpenAI 在 2024 年底先发布了 Swarm(实验性),2025 年初升级为正式的 Agents SDK。核心概念只有两个:
它故意做得很”薄”,不引入 LangGraph 式的状态图,官方哲学是”让模型自己决定路由”。配合 Responses API + Built-in tools(web search、file search、computer use)可以快速搭建。
Anthropic 的官方 SDK 虽然不像 OpenAI Agents SDK 那样强调”agent 框架”,但它提供了两个关键能力:
Computer Use 通常搭配一个 Docker 容器 + VNC + Python
控制层(Anthropic 官方的
anthropic-quickstarts/computer-use-demo)。
HuggingFace 2024 末推出的极简 agent 框架,主打代码即动作(CodeAgent)——让 LLM 直接输出 Python 代码,在沙箱里执行,而不是 JSON tool call。这种模式在多步骤数值与数据处理任务上比 function calling 更强,因为 LLM 可以用变量、循环、条件表达复杂逻辑。
graph LR
subgraph 单Agent
A1[Agent]
end
subgraph Manager-Worker
M[Manager] --> W1[Worker1]
M --> W2[Worker2]
end
subgraph Hierarchical
CEO --> PM
PM --> Dev
PM --> QA
end
subgraph Debate/Swarm
D1 <--> D2
D2 <--> D3
D1 <--> D3
end
工程上多 agent 合理的三个条件:
如果只是为了”架构看起来漂亮”而多 agent,几乎总是退步。
MemGPT(2023,UC Berkeley)把 LLM 上下文窗口类比为”RAM”,把外部存储类比为”硬盘”,让 LLM 通过 tool call 主动把信息换入换出——这就是”memory paging”。Letta 是其后续产品化项目,提供托管 agent 服务。关键能力:
Mem0 定位更轻量:一个 Python
库,配一个可选云服务。特点是把”记忆”抽象成三条基本操作:add
/ search / update,底层可以用
Qdrant、pgvector、Neo4j 等。
from mem0 import Memory
m = Memory()
m.add("我对芒果过敏", user_id="alice")
m.search("过敏史", user_id="alice")Zep 2024 末推出
Graphiti——一个时序知识图谱记忆系统。它会把对话抽取为(实体、关系、时间区间)三元组,图上还记录
valid_from / valid_to,可以回答”去年三月他住在哪里”这类时序问题。适合需要长期跟踪事实变化的
agent(客服、私人助理、医疗)。
Agent 每一步的准确率假设是 95%,10 步后只剩 \(0.95^{10} \approx 0.60\)。工程对策:
工具一多,LLM 就会混:“search 还是 search_web 还是 google_search?”对策:
一次 agent run 跑掉几美元、几十万 token 的例子比比皆是。监控维度:
不插桩的 agent 出问题基本 debug 不出来。必备三件套:
Anthropic 2024 年 11 月开源,定位是“Agent 世界的 USB-C”。客户端(Claude Desktop、Cursor、Continue、Cline 等)通过 JSON-RPC 连接 MCP Server,Server 暴露三类原语:
生态在 2025 年爆发式扩张,GitHub、Notion、Slack、Figma、各大数据库都有官方或社区 MCP server,估计已超过 3000 个。详见下一篇第 20 节。
Google 2025 年 4 月发布,解决的不是 agent 调工具,而是 agent 调 agent。核心概念:
/.well-known/agent.json,声明能力、endpoint、认证方式。A2A 与 MCP 的关系:MCP 让 agent 用工具,A2A 让 agent 雇 agent。两者互补,不排斥。
flowchart LR
U[用户前端] -- AG-UI --> H[Host Agent]
H -- MCP --> T1[Tool Server: GitHub]
H -- MCP --> T2[Tool Server: 数据库]
H -- MCP --> T3[Tool Server: 本地文件]
H -- A2A --> A1[远程 Agent: 报表]
H -- A2A --> A2[远程 Agent: 翻译]
A1 -- MCP --> T4[报表 Tool Server]
可以把三者近似理解成三层:
三者解耦,各自演进,2025 年已基本成为行业共识。ANP 解决的是更底层的”agent 在公网如何认身份”,属于 PKI 级别的扩展。
# server.py
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
def get_weather(city: str) -> dict:
"""查询某城市当前天气(示意)。"""
return {"city": city, "temp_c": 22, "cond": "clear"}
@mcp.resource("weather://alerts")
def list_alerts() -> str:
return "无预警"
if __name__ == "__main__":
mcp.run()在 Claude Desktop 的配置里加上:
{
"mcpServers": {
"weather": {"command": "python", "args": ["/path/to/server.py"]}
}
}重启客户端,get_weather
就出现在工具列表里。对于企业内部工具,这意味着”写一次,到处可用”——今天给
Claude 用,明天同样的 server 给 Cursor、Cline、自建 agent
用,不需要改一行。
Agent 一旦会写代码、能下载文件、会 shell,就必须跑在沙箱里。按隔离度排序:
| 方案 | 隔离度 | 启动 | 用途 |
|---|---|---|---|
| 同进程 exec() | 几乎没有 | 毫秒 | 绝对不要 |
| Docker | 容器级 | 秒 | 自托管,简单场景 |
| gVisor | 内核级用户态 | 秒 | 强隔离 Python |
| Firecracker microVM | 硬件虚拟化 | 100ms 级 | AWS Lambda 同款 |
| E2B | 云托管 Firecracker | 150ms | SaaS 首选 |
| Daytona | 自托管 / 云双模 | 亚秒 | 开发环境沙箱 |
| Modal | Serverless Python | 秒级冷启动 | GPU / 重载计算 |
E2B 是当前 agent 沙箱里最主流的 SaaS,Anthropic、Perplexity、Cognition 等都在用。核心卖点:
sandbox.commands.run("ls") 一行搞定。自托管场景下最务实的组合仍然是 Docker + cgroup limits + 只读 rootfs + 无网络或白名单出口。
Browser Use 是 2024 末火起来的开源库:基于 Playwright + LLM,把网页 DOM 可见元素编号后喂给模型,让模型输出”点第 N 个元素”“在第 M 个 input 填 X”。开源、可自托管,生态活跃。
from browser_use import Agent
from langchain_openai import ChatOpenAI
agent = Agent(task="在 arxiv 上找 2025 年 RLHF 新论文并列出标题",
llm=ChatOpenAI(model="gpt-4o"))
await agent.run()微软官方把 Playwright 暴露成 MCP server,使任何 MCP 客户端(Claude Desktop、Cursor)都能自然语言控制浏览器。适合让编辑器具备浏览能力的场景,而不是自建 agent。
区别于 Browser Use 的 DOM 模式,Computer Use 和 Operator 走的是视觉 + 键鼠路线:
click(x,y) / type(text) /
scroll(dy) 等原子动作。这三个是 端到端 agent 产品,而不是框架:
agent
概念内嵌(subagent、skills)。做选型时要区分:自己搭 agent 框架,还是用现成 agent 产品 + 它们的 API/SDK 二次封装。大多数企业应用后者性价比更高。
| 基准 | 场景 | 核心指标 | 代表成绩(2025) |
|---|---|---|---|
| SWE-bench Verified | 真实 GitHub issue 修复 | 通过率 | 顶级 65–70% |
| τ-bench(Tau) | 用户-agent-商家三方对话 | 任务完成率 + 规则遵守 | 55–75% |
| AgentBench | 8 种环境综合 | 综合得分 | 闭源模型领先 |
| WebArena / VisualWebArena | 真实网页任务 | success rate | 35–50% |
| GAIA | 需要规划+工具的通用任务 | 三级难度通过率 | L1 80%+,L3 40%+ |
| OSWorld | 桌面级任务 | 任务完成率 | 20–40% |
| SWE-Lancer(中文场景可自建变体) | 软件工程竞标 | 美元价值 | 前沿模型显著领先 |
自建评测的工程要点:
生产 agent 离不开这几类基础设施 SaaS:
选型的关键问题:数据留存。如果 prompt/response 涉及用户隐私或商业数据,优先选能自托管的(Langfuse、Phoenix)。
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
from langchain_community.tools.tavily_search import TavilySearchResults
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
tools = [TavilySearchResults(max_results=5)]
agent = create_react_agent(llm, tools)
result = agent.invoke({
"messages": [("user", "总结 2025 年 Q1 关于 MoE 训练的 3 个新进展")]
})
print(result["messages"][-1].content)底层其实是一张两节点状态图:agent → tools → agent → END。想要更复杂行为(校验、重试、人工介入)只需在图上加节点和边。
from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver
import operator
class S(TypedDict):
messages: Annotated[list, operator.add]
plan: list[str]
step: int
def planner(s: S):
plan = ["搜索最新论文", "按机构分组", "提炼共性结论"]
return {"plan": plan, "step": 0}
def executor(s: S):
task = s["plan"][s["step"]]
return {"messages": [f"完成: {task}"], "step": s["step"] + 1}
def router(s: S):
return END if s["step"] >= len(s["plan"]) else "executor"
g = StateGraph(S)
g.add_node("planner", planner)
g.add_node("executor", executor)
g.set_entry_point("planner")
g.add_edge("planner", "executor")
g.add_conditional_edges("executor", router, {"executor": "executor", END: END})
app = g.compile(checkpointer=SqliteSaver.from_conn_string("agent.db"))
app.invoke({"messages": []}, config={"configurable": {"thread_id": "run-1"}})Checkpointer 让这张图天然支持断点续跑、时间旅行、人工介入。
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient
model = OpenAIChatCompletionClient(model="gpt-4o")
coder = AssistantAgent("coder", model_client=model, system_message="你写 Python")
critic = AssistantAgent("critic", model_client=model, system_message="你审代码,最多 3 轮")
team = RoundRobinGroupChat([coder, critic], max_turns=6)
await team.run(task="写一个 LRU 缓存,支持 TTL")from crewai import Agent, Task, Crew, Process
researcher = Agent(role="研究员", goal="找齐材料", backstory="资深情报分析",
tools=[search_tool], llm=llm)
writer = Agent(role="写作者", goal="输出博文", backstory="技术编辑", llm=llm)
t1 = Task(description="调研 MCP 生态现状", agent=researcher, expected_output="要点清单")
t2 = Task(description="写 800 字博文", agent=writer, expected_output="markdown")
crew = Crew(agents=[researcher, writer], tasks=[t1, t2], process=Process.sequential)
print(crew.kickoff())from agents import Agent, Runner
triage = Agent(name="triage", instructions="把请求路由给合适的专家",
handoffs=[billing_agent, tech_agent])
result = Runner.run_sync(triage, "我上周的账单多扣了 30 元")
print(result.final_output)Coze 里搭一个”每天早上总结 arxiv 最新 AI 论文并发到飞书”的 agent:
[定时触发 08:00]
↓
[HTTP 插件] GET arxiv API(cs.CL,最近 24h)
↓
[LLM 节点] 系统提示:筛选 5 条最有价值 + 翻译成中文
↓
[知识库写入] 入库 tag=daily-arxiv
↓
[飞书机器人] 推送到「AI 日报」群
全程无代码,30 分钟能搭完;国内侧可直连豆包/DeepSeek,对接飞书、钉钉、企微插件齐全。缺点是黑盒逻辑改动受限,复杂业务迟早要自建。
flowchart TD
U[User Query] --> A[Agent: 生成 Thought]
A --> B{需要工具?}
B -- 是 --> T[Tool 执行]
T --> O[Observation 注入]
O --> A
B -- 否 --> F[Final Answer]
F --> E[End]
flowchart LR
S([Start]) --> P[planner]
P --> R{route}
R -- research --> RS[researcher]
R -- code --> CD[coder]
R -- review --> RV[reviewer]
RS --> V[verifier]
CD --> V
RV --> V
V -- pass --> E([End])
V -- fail --> P
| 场景 | 推荐 |
|---|---|
| 个人试玩 / demo | OpenAI Agents SDK、Smolagents |
| 国内低代码快速上线 | Coze、百炼 Assistant、千帆 Agent |
| 复杂编排 + 可观测 | LangGraph + LangSmith/Langfuse |
| 多 agent 协作 | AutoGen、CrewAI |
| 类型安全 Python 后端 | Pydantic AI |
| prompt 自动优化 | DSPy |
| 大量文档 RAG + agent | LlamaIndex |
| 浏览器自动化 | Browser Use(DOM)、Computer Use(视觉) |
| 强安全隔离 | E2B / Daytona / Firecracker 自托管 |
| 记忆系统 | 短期=摘要;长期=Mem0 / Letta / Zep |
| 跨 agent / 跨厂商互通 | MCP(工具)+ A2A(agent) |
一个 agent 的上限,很大程度由 tool schema 的清晰度决定。经验法则:
search_papers、create_ticket,而不是
paper、ticket_op。search_repo”——这比正例更能降低误用率。{status, data, error}
三段式优于裸返回;给 LLM 稳定的解析契约。PermissionError: user 'alice' lacks 'write' on repo 'foo'
远好于
403 Forbidden,模型看到后能自己决定换工具或求助用户。OpenAI、Anthropic、Gemini、Qwen 都已原生支持一次响应中返回多个 tool_call,客户端并发执行后把多个 tool_result 一次性回送。工程上要注意:
Agent 接入人工介入有三种层次,成本递增:
interrupt_before=["tool_node"] 原生支持。没有 human-in-loop 机制的 agent 只能做低权限、可撤销的动作;一旦触碰不可撤销操作,必须加门。
一张对标表,经验值(2025 中):
| 动作 | 典型 token | 典型耗时 | 备注 |
|---|---|---|---|
| 单次 LLM 调用(ReAct 一步) | 3k in / 500 out | 2–6s | 取决于模型与上下文 |
| 一次工具调用 + observation | +1k | +0.2–2s | 外部 API 延迟是大头 |
| 一次完整 agent run(5–15 步) | 30k–200k | 20s–3min | 长尾易失控 |
| 浏览器截图一次 computer use | +2k(截图 base64) | +1–3s | 视觉模型推理慢 |
| Code interpreter 一次 exec | 0 tokens | 0.5–30s | Python 冷启动 + 执行 |
由此得到几条务实守则:
max_iterations、max_tokens、max_seconds、max_usd
四道闸。下面把前面抽象的东西落成一个能上线的方案。
flowchart LR
U[IM webhook] --> GW[LLM Gateway]
GW --> R[Router Agent]
R -- 简单检索 --> QA[RAG Agent]
R -- 复杂分析 --> W[Worker Agent]
QA --> VS[(向量库)]
W --> TL[Tools: SQL, Python]
W --> VS
QA --> GW
W --> GW
GW --> LF[Langfuse Trace]
run_sql、run_python(E2B
沙箱)、search_docs。user_id 过滤;漏掉就是数据泄露事故。[doc#N] 的段落丢弃重答。同一需求,三种合理实现:
选哪条路取决于团队规模与长期规划。不要为了短期而锁死在只支持某家模型的平台上——在大模型价格每年腰斩、能力每半年翻倍的节奏下,可替换性比”今天就跑起来”更重要。
几个正在发生、2026 很可能主导 agent 工程的方向:
推理模型把”思考—工具—反思”塞进一次 generate 调用。对框架的影响:更薄的编排 + 更厚的工具层。框架会收敛到:
LangGraph 里那些手写的 reflection 子图会慢慢变成反模式。
MCP server 市场(Smithery、mcp.so、glama)+ A2A agent 市场正在形成。未来三年可能出现”Agent Store”——为某个垂直领域付费订阅一个远程 agent,像今天订阅 SaaS 一样。
当前 agent 主要解决”单次任务”(几秒到几分钟)。下一步是”持续运行 agent”(小时/天/周),代表形态:
这类 agent 对记忆、成本预算、可中断可恢复提出比现在高一个数量级的要求。
视觉 + 语音 + 动作统一进入 agent 循环。表现形式包括:
Agent 框架将承担”把这些模态统一接入工具图”的职责。
Agent 带来的安全风险远超 chatbot:
工程上正在出现专门的Agent Firewall / Guardrail 产品(Lakera、Protect AI、国内的有瑞莱智慧等),走反向代理或 SDK 插桩两条路线。这部分将在第 24 篇详细展开。
为了让”可观测”“错误累积”这类抽象概念落地,我复述一次真实排查:线上客服 agent 偶发”答非所问”,约 2% 的 session 触发。
Langfuse 里按失败标签过滤,发现失败 case 有共性:模型调用次数都在 6+,而正常 case 平均 2–3 次。初步判断是死循环或错误累积。
基于 LangGraph Checkpointer 回放,看到如下片段:
step 1 tool_call: search_kb(q="发票怎么开") -> ok, 3 docs
step 2 tool_call: search_kb(q="开发票") -> ok, 3 docs(和上一步 90% 重叠)
step 3 tool_call: search_kb(q="开发票 流程") -> ok, 3 docs(还是类似)
step 4 tool_call: search_kb(q="开发票 步骤") -> ok, 3 docs
step 5 tool_call: search_kb(q="开票") -> ok
step 6 final: "抱歉我暂时找不到相关信息…"
很明显:模型陷入”换关键词重试”循环,其实第一次就拿到了答案,只是答案对模型来说不够”明显”。
三处改动:
在评测集 200 条里跑回归,原先的 2% 死循环 case 降到 0;顺便整体准确率 +4%。上线后一周监控,p95 延迟下降 1.8s,平均 token 消耗下降 35%。
这个例子里真正起作用的不是”更好的模型”,而是”能看见 trace 才能找到问题”。这就是为什么我在前面反复强调可观测性。
本篇走完了 agent 工程的主要面:范式演进、抽象模型、主流框架、多 agent 拓扑、记忆、协议、沙箱、浏览器控制、评测与基础设施。几条工程上反复验证的经验:
下一篇将聚焦工具调用与 MCP:工具 schema 设计、并行 tool_call、MCP server 工程实践、跨 agent 互操作的具体协议细节。
以下是 2025 年工程界真实在用的开源项目清单,按用途分类:
把一个原型 agent 推到生产前,请过一遍这份清单:
稳定性
安全
可观测
质量
成本
协议化
过完上面 25 条,你的 agent 才真正配得上叫”基础设施”。
本篇走完了 agent 工程的主要面:范式演进、抽象模型、主流框架、多 agent 拓扑、记忆、协议、沙箱、浏览器控制、评测与基础设施。几条工程上反复验证的经验:
下一篇将聚焦工具调用与 MCP:工具 schema 设计、并行 tool_call、MCP server 工程实践、跨 agent 互操作的具体协议细节。
把当前热点继续串成多页阅读,而不是停在单篇消费。
2026-04-22 · architecture / ai-infra
面向工程师的大模型基础设施开篇地图,覆盖 2022 到 2026 的工程分水岭、五层工程栈、训练与推理的工程差异、中国与全球行业版图以及成本曲线。
2026-04-22 · architecture / ai-infra
从 OpenAI function calling 到 Anthropic MCP,深入剖析大模型工具调用的格式、结构化输出、并行调用、协议设计与工程安全边界。
2026-04-22 · architecture / ai-infra
面向中国工程团队的大模型基础设施系列。从 GPU/CUDA/互联、训练框架与 3D 并行、vLLM/SGLang 推理引擎、量化与推测解码、RAG/Agent 到服务化、网关、可观测性与安全合规,覆盖 LLMOps 全链路。
2026-04-22 · architecture / ai-infra
从 CPU 与 GPU 的架构差异出发,讲清楚 SM、Warp、Tensor Core、HBM、NVLink 的工程含义,并结合 Roofline、FlashAttention 与国产算力栈,给出大模型工程师能直接上手的 GPU 心智模型。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。