一句话定义：Agent = LLM 大脑 + 循环 感知→决策→行动→观察 + 工具 + 记忆，由模型在运行时动态决定下一步。

参考架构：4 + 1（大脑 / 规划 / 记忆 / 工具 + 环境闭环），工程化版本再补 4 个外围（调度、护栏、可观测、UI）。

三者本质都是"LLM + 工具"的组合，区别在于能不能表达分支、循环和断点续跑。Chain → Agent → Graph 是逐步加强表达力的演化路径。

"自主"不是魔法，本质是把 LLM 当策略函数 π(a|s)，外面套一个 while 循环，每次把"该做什么"转化成模型的下一个 token 预测。

while not done and step < max_steps:
    obs    = perceive(env)                              # ① 观察
    state  = update_memory(state, obs)                  # 写入短期记忆
    action = LLM(prompt(state, tools_schema, history))  # ② 模型 = 策略函数
    result = execute(action)                            # ③ 工具执行
    state  = update_memory(state, result)               # ④ 反馈回灌
    done   = is_finished(state)                         # 终止条件

Andrew Ng 总结的四大设计模式（Reflection / Tool Use / Planning / Multi-Agent），工程上再补两种编排模式（Router / Hierarchical）。

工业界经常混用，但严格说是"实体"对"范式"的差别。类比就是 Microservice（一个服务） vs Microservices Architecture（一种架构风格）。

推荐 8 步设计法。顺序很重要——评测要先于 Prompt，工具要先于规划范式。

四个判定维度：任务确定性 × 步骤稳定性 × 容错成本 × 延迟敏感度。任一个偏紧，都倾向 Workflow。

两类故障都是"自由度太高"的副产物。幻觉是输出失真，循环是动作失控，解法在于多层约束。

本质差异："模仿动作" 还是 "理解意图"。RPA 是录屏式重放，Agent 是带脑子的执行者。

核心 = Self-Attention + FFN + Residual + LayerNorm，N 层堆叠。关键公式：Attention(Q,K,V) = softmax(QKT/√d)·V。

三段式 = 宪法 + 输入 + 历史。理解关键：从上到下，稳定性递减、长度变化递增，所以缓存策略也是从上到下递减。

三种"喂法"，对应"不给例 / 给例 / 让它想"三档强度，token 成本递增，效果也递增。

推荐 RICE-O 五段式：RoleInstructionContextExampleOutput。

采样参数本质都是"从 LLM 输出概率分布里选哪个 token"的策略。Agent 不同环节对"创造力 vs 稳定性"需求不同。

三个强度递增的"给模型套笼子"方案。越往下越严格、合规率越高，但灵活性越低。

{
  "type": "object",
  "properties": {
    "intent":  { "type": "string", "enum": ["refund", "complaint", "query"] },
    "order_id":{ "type": "string", "pattern": "^O[0-9]{8}$" },
    "amount":  { "type": "number", "minimum": 0 }
  },
  "required": ["intent", "order_id"],
  "additionalProperties": false
}

本质 = 复用注意力的 KV Cache。命中部分按 ~1/10 价格计费，首 Token 延迟降 50%+。这是 Agent 降本最快的杠杆。

5 种主流策略，本质都是 "用更少的 token 装下足够多的信息"。可叠加使用。

Token 是模型处理的最小单位。BPE/WordPiece/SentencePiece 把字符串切成可学习子词。Agent 工程师必须懂，因为它直接关联成本 / 上下文 / 安全。

核心原则："Prompt 是代码，必须有测试"。流程化 4 步 + 4 类指标 = 可量化的迭代闭环。

ReAct = Reasoning + Acting。模型在 ThoughtActionObservation 三种 token 之间交替，把"决策过程"显式化为可被代码解析的 token 流。

You can use the following tools:
- search(query): web search
- calc(expr):    math

Use this format:
Thought:  ... what to do next
Action:   tool_name(arg)
Observation: <tool result>
... (repeat Thought / Action / Observation)
Thought:  I now know the answer.
Final Answer: ...

核心差别："步步为营 vs 一次画图"。前者灵活高 token，后者高效但僵化。混合模式（Plan 出大纲 + 子任务跑 ReAct）是生产首选。

"让模型自我审查"。Reflection = 单次审查；Reflexion = 把失败教训写进记忆，跨轮可用。原论文在 HumanEval、HotpotQA 提升 10-20%。

把"线性 CoT"升维成"搜索树/图"：每一步生成多个候选，按评分剪枝。表达力强但 token 爆炸。

两者都属于"多次采样 + 选最优"家族。Self-Consistency 用投票，Best-of-N 用评分器——前者是后者的特例。

"大脑分层"——高层 Planner 决定做什么，低层 Executor 决定怎么做。任务超过 10+ 子步骤、跨多领域时必须分层，否则上下文爆炸 + Plan 漂移。

Meta 提出的事实校验范式：模型先答 → 自己出验证问题 → 逐题查证 → 修订答案。在事实型问答上能显著降幻觉。

2026 年主流模型（GPT-5 thinking / Claude 4.x extended thinking / Qwen3-thinking / DeepSeek-R1）都支持显式思考。关键不是"开 vs 关"，而是"按任务难度调档"。

"长任务规划漂移"的本质是：模型记不住自己最初的目标。解法是把规划从模型脑里搬到外部 state。

规划评测是多维向量，不能只看"是否解决"。下面 5 个维度组成一个雷达图就是规划质量画像。

本质 = 把"调用哪个函数 + 参数" 作为模型的结构化输出。SDK 拿到后调用真实函数，把结果作为新消息回灌——这就是 Agent 工具循环的标准范式。

工具描述本质是给模型看的 API 文档。四个高 ROI 点把"能用"提升到"用得对"。

{
  "name": "helper_1",
  "description": "搜索",
  "parameters": {
    "q": {"type": "string"}
  }
}

{
  "name": "search_internal_kb",
  "description": "在内部知识库（HR/IT政策）做语义检索。
    适用：员工提问的政策问题。
    不适用：实时数据、外部新闻。",
  "parameters": {
    "query":   {"type":"string", "example":"年假天数"},
    "top_k":   {"type":"int", "default":5, "max":20},
    "lang":    {"type":"string", "enum":["zh","en"]}
  },
  "errors": {"INVALID_LANG":"lang 必须是 zh/en"}
}

同一轮生成多个独立 tool_call，并行执行。优势：一次回合搞定多事情，减少 round-trip。前提：工具间无依赖。

MCP（Model Context Protocol）= Anthropic 提出、已成行业事实标准的开放协议。最大价值是把 M×N 集成爆炸收敛为 M + N。

记住一个核心区分：谁来决定加载。Tool 由模型主动调用，Resource 由用户/客户端决定，Prompt 由用户唤起，Sampling 由服务器反向请求客户端。

三种传输，差别在本地 vs 远程 / 单向 vs 双向。

Python 用 mcp 官方 SDK（FastMCP 风格），15 行代码就能跑起来。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-tools")

@mcp.tool()
def add(a: int, b: int) -> int:
    """两数相加。a/b 为整数，返回它们的和。"""
    return a + b

@mcp.resource("file:///{path}")
def read_file(path: str) -> str:
    """读取本地文件的纯文本内容。"""
    return open(path).read()

@mcp.prompt()
def summarize(text: str) -> str:
    """总结一段长文。"""
    return f"请用 3 句话总结：\n{text}"

if __name__ == "__main__":
    mcp.run()                                       # stdio
    # mcp.run(transport="streamable-http", port=8080)  # 远程

工具调用是 Agent 故障的"前沿"。四层防御一个都不能少：分层超时 / 重试退避 / 结构化错误回传 / 降级兜底。

"四层防线 + 审计闭环"。每一层独立、可单独审计，缺一层都可能被绕过。

模型默认不会主动放弃——它倾向于"乱造一个动作交差"。给它合法的退出路径是关键。

[System Prompt 末尾]
=========================
你的能力边界：
- 你可以读取/搜索代码、执行 bash、修改文件
- 你不能：访问内网生产数据库 / 发送邮件 / 修改 CI 配置

如果用户请求超出能力：
1) 调用 ask_user(question)  追问澄清
2) 调用 escalate(reason)    升级给人类
3) 直接回答："这超出我的能力，我无法完成"

不要尝试发明不存在的工具名。

RAG = Retrieval-Augmented Generation：用检索结果增强生成。完整链路分离线侧（建库）和在线侧（查询）。

切片质量直接决定召回上限。"按字数硬切" vs "按语义切" 的效果差距可达 20-30%。

五个选型维度：语种 / 任务 / 长度 / 成本 / 私有化。先看 MTEB/C-MTEB 排行，再用自有评测集小样本对比。

选向量库主要看数据规模，其次看是否需要复杂过滤 / SQL 联表 / 多模态。

四大主流 ANN（近似最近邻）索引。所有索引都在做"召回率 ↔ 延迟 ↔ 内存"的三角形权衡。

向量擅长"语义相近但词不同"，对精准实体（人名、编号、产品ID、SKU）反而弱。BM25 正好相反。两者互补 → Hybrid 召回。

Rerank 用Cross-Encoder 把 query + 单条 doc 一起喂入模型计算精细相关性。比 embedding 相似度更准。RAG 单 trick 中 ROI 最高。

用户的原始 query 通常对检索不友好（指代、模糊、口语化）。查询改写是检索前的"润色"环节。

三层评测：检索 → 生成 → 业务。任何一层出问题都会拖累整体效果，但定位故障源需要每层都有独立指标。

把 RAG 从"一锤子买卖"升级为"可被 Agent 多次调用的工具"，循环 Retrieve → Reflect → Retrieve 直到足够。

类比认知科学，Agent 记忆分"按时长"和"按内容"两组分类。两个分类正交，不要混淆。

最小可用 = 滚动窗口 + 阈值摘要 + 持久化。50 行代码足够。

def chat(user_input, session_id):
    history = redis.lrange(f"sess:{session_id}", -20, -1)  # 取最近 N 轮
    summary = redis.get(f"sess:{session_id}:summary") or ""
    messages = [{"role":"system","content": SYSTEM}, {"role":"system","content": summary},
                *history, {"role":"user","content": user_input}]
    reply = llm.chat(messages)
    redis.rpush(f"sess:{session_id}", json.dumps({"u":user_input, "a":reply}))
    if count_tokens(history) > 8000:                   # 超阈值 → 压缩
        new_summary = llm.summarize(history[:-10])
        redis.set(f"sess:{session_id}:summary", new_summary)
        redis.ltrim(f"sess:{session_id}", -10, -1)
    return reply

"什么都存"是新手最大坑——信噪比骤降，召回时混杂大量垃圾。"按价值过滤"是核心原则。

"召回 + 排序"两步走，类似 RAG。新鲜度 / 相关性 / 重要性 三者加权排序。

把 LLM 当操作系统：上下文 = 主存，外部存储 = 硬盘。Agent 自己用工具 paging in/out 数据，从而突破上下文限制。

"记忆熵增"是长期 Agent 的天敌：重复 / 冲突 / 过期 / 跨域污染。需要主动维护。

双轨制 = 摘要保宏观连贯 + 检索保精准引用。两者并行注入 prompt，相互补强。

多租户场景"记忆串了"=数据安全事故。必须从代码层强制隔离，不能依赖 prompt 自觉。

不是 OR，是 AND。向量擅长模糊语义，KG 擅长精确关系。生产用法是"向量主存 + KG 处理实体关系子集"。

"三类技术指标 + 业务指标"。仅看召回率会漏掉关键问题——召回了但模型没用、用了但已过时。

LangChain 提供 LLM 应用的通用抽象层。最有生命力的是 LCEL（LangChain Expression Language）——用 | 把组件像 Unix Pipe 一样串起来。

LangGraph 把 Agent 显式建模为有状态有向图：StateNodeEdgeConditional Edge。每个节点是函数（含 LLM），状态在节点间流转。

核心定位差异："数据中心" vs "编排中心"。在生产里其实常混用——LlamaIndex 做检索子模块，LangGraph 做主流程。

AutoGen 把多 Agent 抽象为"对话型协作"——每个 Agent 是一个角色，通过 Group Chat / Sequential / Nested chat 互相发消息。

"流程驱动 vs 消息驱动"。CrewAI 像编剧给角色发剧本，AutoGen 像把演员扔进房间让他们自己聊。

定位 = 面向产品 / 业务方的可视化 Agent 工厂。开发者用代码框架，产品 / 业务方用低代码平台——是互补不是竞争。

看似不同的产品（CLI / IDE 插件 / 桌面）共用一套"5 层"架构：主循环 + 分层指令 + 权限 + 子代理 + 记忆/技能。

两家都在把"主循环 SDK 化"，开发者越来越少手写 ReAct prompt。差别主要在生态绑定 / 协议侧重。

"能用框架的尽量用，框架卡死的果断自研"。三类场景框架会成为累赘。

2026 年新派的 Agent 框架，主打"类型安全 + DX 现代化"。语言生态决定了它们的目标用户。

"能单 Agent 做好的，绝不上多 Agent"。多 Agent 的通信代价 + 一致性难度会迅速吃掉收益。

六种主流编排模式，按"中心化程度"排列：从最强中心化（Supervisor）到最松散（Swarm）。

三大协议正在形成"分工矩阵"：MCP 管 Agent↔Tool，A2A / ACP 管 Agent↔Agent。

三种范式：黑板（共享内存）/ 消息（Actor）/ 事件（发布订阅）。耦合度递减，可观测性递增。

"任务漂移"是多 Agent 最常见故障：Worker 越做越偏。解法是把"目标"显式化、可校验、可终止。

多 Agent 死循环模式：A→B→A→B... 或 调用图爆炸。四道闸门按"轻 → 重"逐层守。

"测试金字塔"在多 Agent 同样适用：底层大量单 Agent 单测，向上递减，顶层少量 E2E + 故障注入。

"你是一个 X 专家"是新手最大误区——所有 Agent 都听这一句，最后都长得一样。责任 + 边界 + 输出契约 才是关键。

你是一个资深的代码工程师。
你的工作是帮助用户完成编码任务。
请认真完成。

你是 Code-Worker，专注 Python 后端实现。
职责：
- 根据 Lead 给的 spec 写代码、跑测试
不在你范围：
- 不要修改 CI/CD
- 不要新增依赖（如需 → escalate）
- 不要决定架构（架构 Q 由 Lead）
工具：read/write/bash/test
输出契约（JSON）：
{ "status": "ok|partial|fail|escalate",
  "files_changed": [...],
  "tests_passed": int }

类比微服务的"服务注册中心"：每个 Agent 暴露 manifest，Supervisor 按能力检索 + 健康状态选择最合适的 Worker。

多 Agent 的token 消耗很容易 5-10× 单 Agent。五个杠杆缺一不可。

四层金字塔评测：从底层组件到顶层业务，每层独立可测、可定位故障。

LLM-as-Judge 失败率最高的两个原因：① 打分尺度模糊 ② 位置偏差。五个技巧叠加可以让相关性从 ~0.5 提到 0.8+。

"答对了 ≠ 走对了"。终态评测看不到过程浪费、绕路、违规调用，轨迹评测补上这一层。

Agent 可观测 = 传统三柱（Trace/Metrics/Logs） + LLM 专属属性（gen_ai.*）。OTel + LLM 语义约定已成事实标准。

Prompt Injection 是 LLM 应用的"SQL 注入"。攻击载体已从用户输入扩展到所有外部内容：网页、邮件、文档、工具结果。没有单点银弹，只有多层防御。

Jailbreak 是"诱使模型违反 system prompt"。Prompt Injection 是注入新指令，Jailbreak 是绕过现有指令——常组合使用。

Guardrails = 在 LLM 输入 / 输出 / 工具调用前后插入策略检查点。早拦便宜，晚拦兜底。

PII 不是"用了再说"，要在入口/中间/出口都设防。四原则：最小化 / 区域合规 / 不记忆 / 全审计。

"线上效果一定会衰减"是事实，问题是多久能发现 / 多久能修。四个衰减源头各有对策。

红队不是"上线前测一次"，而是"持续对抗 + 永不退役回归集"。每次模型 / Prompt / 工具变化都要触发。

生产级架构 = 统一入口 + Agent 服务 + 多支撑组件。核心是模型走 Gateway 而非直连 SDK。

路由 = "把对的请求发给对的模型"。常见 5 个维度，可组合使用。

三种流式传输的核心差异：单向 vs 双向 / 浏览器友好 vs 自定义协议。

"Key 是钱、是 QPS、是合规风险"。一个 Key 池管理不善的 Agent 系统，可能 24h 内被刷爆。

Agent 总延迟 = Σ(LLM 推理 + 工具调用 + 网络)。优化按 ROI 排序：缓存最先做。

"Agent 没法回归测试到位"——必须靠灰度 + A/B 在真实流量上验证。关键是对照指标 + 自动回滚。

Agent 服务的特点是"长任务 + 高并发 IO"。Python 部署有 6 个易踩坑点。

私有化部署的 6 大决策矩阵，每个决策错了都会显著影响吞吐 / 成本 / 合规。

"立项时算 ROI，上线后看真账单"。三块成本 vs 三种收益的对照表。

STAR-R 五段式：Situation / Task / Action / Result + Reflection。比纯技术细节更打动面试官的是"反思"那一段。