今天这篇文章的目标。就是帮你从“听过”走到“看懂”，再走到“能讲给别人听”。

全文按照从具体到抽象、从直觉到原理的顺序组织：先用一个主要公式建立整体认知。再用一个真实例子感受 Agent 怎么工作，接下来逐层深入每个组件、每道工序。读到不懂的地方不必纠结，先往下走。很多概念会在后文反复出现，第二次见到时会豁然开朗。

一、 ：你已经在使用 AI Agent 了

使用者痛点 1：不知道自己已经在使用 Agent——很多人以为自己只是在和聊天机器人对话，却忽略了这些产品已经具备了 Agent 的主要特性。

如果你在用 Claude Code 写代码、阅读代码；用千问帮你点外卖，用豆包深度研究某一个问题，其实已经使用 AI Agent 了。这些产品形态各异，但有一个明显的共同点：它们不再是“你问一句、它答一句”的对话。而是能够自己规划执行步骤、调用各种工具完成任务，并不断调整策略的智能程序。

要理解这种变化的意义，不妨回顾一下人机交互的演进史：从命令行到图形界面再到触摸交互。每一次范式跃迁都极大地降低了人使用计算机的门槛，也释放了新的应用形态。Agent 所代表的，是交互范式的又一次跃迁——从“人学会操作机器”转向“机器学会理解人”。你不再需要点击菜单、填写表单、记住快捷键，只需用自然语言描述意图。Agent 就会自主拆解任务、调用工具、完成执行。这代表着，过去需要专业软件技能才能完成的工作，正在变得人人可用。

二、现代 Agent 的主要内容

三个词概括 Agent 的本质

现代 Agent 程序的本质可以用一个简洁的公式来表达：

这三个词分别对应三个部分：

• 决策引擎决定“做什么、怎么做”。它理解你的意图、规划执行步骤、做出判断。把它想象成一位刚入职的聪明实习生——脑子很快，但还需要看资料、用工具才能把事情真正做成。
• 信息视野决定“能看到什么、知道什么”。包括环境信息、使用者记忆、领域知识、任务进展等。就像实习生办公桌上摊开的所有资料——邮件、文档、同事口头交代和笔记本。
• 执行通道决定“能改变什么、能影响什么”。包括 API 调用、代码执行、浏览器操作和子 Agent 协作等。就像实习生能使用的所有手段——电脑、软件、打印机、电电话还有向同事求助。

整体上来看。决策引擎是“想”，信息视野是“看”，执行通道是“做”。三者缺一不可，任何环节薄弱都会成为程序瓶颈。

User Pain Point 2：组件不匹配导致性能瓶颈

如果决策引擎强大但信息视野不足。或工具设计混乱，都可能让整个程序表现平庸。下面通过类比帮助你直观感受：

Agent 组件	宴席类比	关键问题
决策引擎	厨师的烹饪判断力	做什么菜？ 顺序，搭配？
信息视野	食材库存·宾客名单·过敏信息·菜谱	有什么食材？谁要来，有什么禁忌？
执行通道	刀·灶·烤箱·帮厨·采购员	能切？能炒，能烤？能让人去买，不过，

The chef can’t cook a great meal if he lacks ingredients or tools . Similarly。an Agent fails if any of its three components is weak.

三、Agent 是怎么工作的：ReAct 循环

动态运行的——它会一步步思考、行动、观察结果，再思考。这一动态过程叫 ReAct 循环。

什么是 ReAct

ReAct 是 “Reasoning + Acting”的缩写，由研究人员在 

The ReAct loop consists of three actions per iteration:

1. The Thought step: The model reasons about next move based on all currently visible information.
2. The Action step: The model decides which tool to invoke and with what arguments.
3. The Observation step: The tool returns a result that is appended to visible context for next round.

This cycle repeats until model decides task is complete and emits a final answer.

至于轨迹。循环的执行记录

An execution of an Agent leaves behind a complete “action log”,called a T​rajectory​​.The trajectory is an ordered list of messages that records everything from user query to final answer.

trajectory = },{ "role": "tool","content": "找到8趟高铁，推荐G2次07:00发车，二等座553元..." },{ "role": "tool","content": "找到10家酒店，推荐前门附近3家，均价480元/晚..." },# 第二次迭代 – 基于结果搜索景点和餐厅
{ "role":"assistant","reasoning":"交通住宿确定，总费用约1106元+960元=2066元；剩余预算约5934元，搜索历史景点和烤鸭餐厅...","actions":}},{"name":"search_restaurants","args":{"city":"北京","tags":,"near":"前门"}}
]},{ "role":"tool","content":"推荐景点：故宫博物院..."}。{ "role":"tool","content":"推荐餐厅：全聚德前门店..."},# 第三次迭代 – 生成最终行程
{ "role":"assistant","reasoning":"所有信息已收集完毕，生成3天行程...","content":"FINAL ANSWER: 上海→北京3天行程…"
}
]

The trajectory does not show system prompts and tool definitions—y are static prefixes automatically attached before each LLM call.

This chronological chain gives each LLM invocation a global view of everything that has happened so far—user intent,previous thoughts,and all tool results—enabling coherent multi‑step reasoning.

至于上下文累积性，ReAct 的精妙之处

The power lies in **cumulative context**. Every LLM call sees full trajectory,allowing it to understand which stage of task it’s in and what has already been tried.

This structure also provides high interpretability and debuggability—each user message,model thought/action pair,and tool result are clearly delineated. When something goes wrong you can pinpoint wher it was a faulty thought,a bad tool call,or an unexpected observation.

说到消融实验。理解循环的诊断方法

A robust way to understand any system is **ablation**—remove one component at a time and see how performance degrades.

• Taking away “tool result feedback”: The agent calls tools but never sees ir outputs in trajectory → infinite loops because it cannot learn from past actions. Feedback is essential for convergence.
• Taking away “thought process”: Model can only output tool calls without reasoning → many wrong calls or malformed arguments. Explicit reasoning lets model “think before acting”.
• Taking away “history trajectory”: Each LLM call sees only its current step → loss of multi‑step capability. Trajectory accumulation is foundational for complex tasks.

四、大组件深度剖析

工具的观点是，Agent 的执行通道

工具四种形态

• 预定义工具：固定输入输出格式，如 search_web或 send_email。行为可预测，就像扳手一样直接可用。按理说，
• 按需加载技能： 当工具数量众多时动态加载相关描述。以免占满上下文空间，类似图书馆按需取书。
• 动态生成代码：Agent 可写代码并即时运行，例如使用 Python 分析 CSV 并绘图。这赋予了 **创造新工具** 的能力。怎么说呢，
• 子 Agent 协作：主 Agent 将子任务委托给专门 Agent。例如研究子 Agent 或编程子 Agent。说起来，类似公司内部部门协作。

设计原则

• 单一职责：每个工具只做一件事并做好它，使组合更灵活。
• 描述清晰：名称/参数/返回格式必须易于模型理解，否则模型选错工具并非自身错误。
• 失败可恢复：返回结构化错误信息，让 Agent 能够重新尝试或切换方案。

至于LLM，决策引擎

能力来源 : 预训练 + 后训练

• 预训练 :海量文本学习语言规律与世界知识——相当于读万卷书但未必会实际操作。
• 后训练 :通过监督微调 与强化学习 教模型如何在具体任务中调用工具并进行决策。对 Agent 这一步很关键，否则模型只能提供文字答案而不会真正行动。

趋势

Kimi K‑Series 等新一代模型通过 RL 将「何时调用哪种工具」内化为原生能力，实现了 **模型即 Agent** 的范式转变。从「被指挥实习生」变为「自主管理项目经理」。虽然框架仍然关键，但未来工程主要将转向让模型自行规划与调度。

信息视野

信息架构

• 程序提示词 / 工具定义 / 使用者记忆 / 检索知识 / 轨迹 / 当前提问。每层负责不同粒度的信息提供，让模型始终拥有最相关的数据视角。

<\/ td

<\/ td

<\/ td

<\/ td

<\/ td>

<\/ td>

<\/ td>

<\/ td>

---