文章目录
LLM：系统的大脑
LLM（Large Language Model，大语言模型）本质上是一个“下一 token 预测器”，它在海量语料上训练后，具备了非常强的语言理解与生成能力。
你可以把它理解成：
- 知识压缩器：把大量公开知识压缩进参数
- 模式匹配器：根据上下文推断最可能的后续表达
- 推理近似器：在某些任务上呈现出类似“推理”的效果
但要注意：
LLM 不是数据库，也不是 deterministic（确定性）程序。它会受提示、上下文、采样参数影响，输出并非每次完全一致。
Token：模型的“字节货币”
Token 不是“字”也不是“单词”，而是模型分词器切分后的最小处理单元。
在中文里，一个字可能是一个 token，也可能多个字组成一个 token。
为什么 token 很关键？
- 成本：多数模型按输入/输出 token 计费
- 延迟：token 越多，处理通常越慢
- 上限：模型有上下文窗口限制（例如 32k、128k、1M）
- 质量：冗余上下文会稀释有效信息，影响回答质量
做 AI 应用时，token 管理是第一等工程问题，不是优化细节。
Context：模型“此刻能看到的一切”
Context（上下文）是模型在本次调用里可见的信息总和，通常包括：
- 系统提示词（System Prompt）
- 用户输入（User Prompt）
- 历史对话（Chat History）
- 检索内容（RAG 片段）
- 工具返回结果（Tool Results）
关键事实：模型不会“自动记住你的系统”。
每一次调用，你都要显式提供它完成任务所需的上下文。
这会带来三个常见策略：
- 裁剪（Truncation）：丢弃最旧且价值低的历史
- 摘要（Summarization）：把长对话压缩为结构化记忆
- 检索（Retrieval）：只注入“与当前问题相关”的外部信息
Prompt：你和模型的“沟通协议”
Prompt 不只是“提问一句话”，而是任务边界、输出格式、行为约束的组合设计。
一个高质量 Prompt 往往包含：
- 角色：你是谁（例如“资深后端工程师”）
- 目标：要完成什么
- 约束：不能做什么、必须满足什么
- 输入结构：给模型什么数据
- 输出格式：JSON、Markdown、步骤列表等
实践中建议把 Prompt 分层：
- 系统层：长期稳定原则（语气、边界、安全）
- 任务层：当前任务目标与判定标准
- 数据层：用户输入、上下文片段、工具结果
Tool：让模型真正“做事”
只靠语言生成，模型只能“说它会做”。
接入 Tool 后，模型才能“真的去做”。
常见 Tool 类型：
- 查询类：数据库查询、搜索、知识库检索
- 操作类：发消息、创建工单、调用业务 API
- 执行类：运行脚本、读写文件、触发流水线
典型调用闭环：
- 模型判断需要工具
- 产出结构化工具调用参数
- 系统执行工具并拿到结果
- 将结果回填给模型继续推理
- 模型给出最终可读结果或下一步动作
MCP：模型与工具之间的“通用插座”
MCP（Model Context Protocol）可以理解为 AI 时代的标准化连接协议。
它让模型/客户端可以用统一方式接入外部工具与资源，而不是每家都造一套私有接口。
MCP 的价值在于：
- 标准化：统一的能力暴露与调用方式
- 可移植：同一工具可被不同 Agent/客户端复用
- 可扩展：新增能力不必大改主程序架构
- 可治理：权限、审计、边界更清晰
如果把 Agent 看作“操作系统上的应用”，那 MCP 更像“硬件驱动 + 总线规范”。
Agent：能自主完成目标的执行体
Agent 不等于“能聊天的机器人”。
更准确地说，Agent 是一个围绕目标持续运行的闭环系统：
- 理解目标
- 制定或调整步骤
- 调用工具执行
- 观察结果
- 继续推进，直到完成或中止
一个最小 Agent 通常包含四个模块：
- Planner（规划）：决定做什么
- Executor（执行）：调用工具做事
- Memory（记忆）：保存短期/长期状态
- Critic（反思）：检查结果是否达标
Agent Skill：可复用、可组合的能力单元
Agent Skill 可以理解为“可插拔能力包”。
它通常封装了某类稳定任务的最佳实践，比如：
- “生成周报并发 Slack”
- “读取日志并定位异常根因”
- “创建 PR 并补齐测试说明”
一个 Skill 往往包含：
- 任务说明（何时使用）
- 输入输出契约（参数、返回格式）
- 工具清单（可调用的外部能力）
- 约束与失败策略（超时、重试、兜底）
好处是：
你不必每次从零写 Prompt，而是把经验固化为可复用模块，逐步形成团队级 AI 能力资产。
Agent 核心模式一：ReAct
ReAct = Reason + Act（推理 + 行动交替）。
它的核心思想是：Agent 每走一步都先思考，再行动，再根据观察结果继续思考。
典型循环：
- Thought（思考）：下一步该做什么？
- Action（行动）：调用哪个工具？
- Observation（观察）：工具返回了什么？
- 回到 Thought，直到完成
ReAct 的优点：
- 反馈快，适合动态任务
- 对不确定环境更鲁棒
- 可以边执行边纠错
ReAct 的挑战：
- 步骤多时 token 消耗较高
- 可能出现“反复试错”导致效率下降
- 需要防止无意义循环调用工具
适用场景：
故障排查、开放信息检索、需要实时依据结果调整策略的任务。
Agent 核心模式二：Plan-and-Execute
Plan-and-Execute（先规划再执行）强调先给出全局计划，再按计划推进。
典型流程：
- Plan：拆解目标，形成任务树
- Execute：逐项执行子任务
- Replan（可选）：若偏离预期，再做局部重规划
- 汇总输出最终结果
优点：
- 全局性更强，路径更可控
- 适合多步骤、依赖关系明显的任务
- 易于审计与协作（计划可检查）
挑战：
- 初始计划可能基于不完整信息
- 环境变化快时，计划会过时
- 过度规划可能增加前置开销
适用场景：
长流程任务、交付物明确的项目推进、需要多人协作或可审计执行链的场景。
ReAct vs Plan-and-Execute：如何选型？
可以用一句话判断：
- 信息不确定、边走边看：优先
ReAct - 目标清晰、流程较长：优先
Plan-and-Execute
工程上常见的是混合模式：
- 先用 Plan-and-Execute 做粗粒度规划
- 每个子任务内部再用 ReAct 动态执行
这也是很多“看起来很聪明”的 Agent 产品背后的通用架构。
从概念到落地：一个实用最小闭环
如果你准备从 0 到 1 做一个 Agent，可以按这个顺序：
- 定义一个非常具体的业务目标（例如“自动整理日报并发到飞书”）
- 写清输入、输出、验收标准
- 设计 Prompt 与上下文裁剪策略
- 接入 1~2 个关键 Tool（先少后多）
- 选一个模式起步（ReAct 或 Plan-and-Execute）
- 记录每次调用链路（可观测性）
- 基于失败案例迭代 Prompt、Skill、工具权限
最容易被忽略但最关键的一点：
先做可观测，再做“更智能”。
没有可观测性，你几乎无法稳定迭代 Agent。
结语
AI Agent 不是一个单点技术，而是一套系统工程：
以 LLM 为核心、以 Prompt 和 Context 为输入控制、以 Tool/MCP 为执行通道、以 Skill 为复用资产、以 ReAct 与 Plan-and-Execute 为行动范式。
当你把这些概念连成一个闭环，AI 才会从“会回答问题”，走向“能持续交付结果”。