题1：Agent 的四大核心组件是什么？分别做什么？#

参考回答（面试口语化）：

Agent 本质上是把 LLM 当大脑，然后给它配了三个手脚——规划、记忆、工具，再加上一个执行循环把它们串起来。

具体来说就是四部分：

① 规划（Planning）：把用户的一个大目标拆解成可执行的子任务。背后用的技术包括 CoT（思维链，一步步推理）、ReAct（推理+行动交替）、ToT（思维树，多条路径探索）、还有 Self-Reflection（自我反思，做错了能回头修正）。面试官如果追问”你的 Agent 怎么拆任务的”，你就说用的是 ReAct 循环 + 子目标分解。

② 记忆（Memory）：分三层。短期记忆就是当前的 Context Window，存的是本轮对话上下文；工作记忆是当前任务做到哪一步了、已经拿了什么中间结果；长期记忆是跨会话持久化的，存在向量数据库里，下次见面还能想起你。面试官常追问”什么时候写入长期记忆”——答案是任务完成时、用户明确要求时、或者检测到重要信息出现时。

③ 工具使用（Tool Use）：让 Agent 能调用外部 API、查数据库、操作文件、控制浏览器。底层就是 Function Calling 或者 MCP 协议。工具的设计很关键——description 写得好不好直接决定模型会不会正确调用，工具粒度太粗模型看不懂，太细又增加调用次数。

④ 执行（Action/Execution）：把规划和执行串起来的循环。Agent 不是一次完事，而是 Observe → Think → Act → Observe 的循环，每一步都基于上一步的结果做下一步决策。异常处理也在这里——重试、降级、上报，三层兜底。

面试加分总结：

“Agent = LLM(Brain) + Planning + Memory + Tool Use，四个组件通过 ReAct 循环协同工作。“

题2：ReAct / Tool Use / Plan-and-Execute / Multi-Agent 四种范式对比？#

参考回答（面试口语化 — 高区分度回答）：

这道题最大的坑就是认为它们是线性进化关系——Tool Use 最低级，ReAct 高级一点，Plan-and-Execute 更高级，Multi-Agent 最牛。这是错的，面试官一听就知道你没理解本质。 实际上它们是不同维度的东西，可以叠加使用：

1
组织架构层  →  Multi-Agent
2
流程控制层  →  Plan-and-Execute
3
推理框架层  →  ReAct
4
基础能力层  →  Tool Use / Function Calling

Tool Use（基础能力层）：模型自主决定要不要调工具、调哪个、传什么参数。优点是延迟低、架构简单；缺点是缺少全局规划，容易跑偏。适合查天气、发邮件这种单一调用场景。

ReAct（推理框架层）：Thought → Action → Observation 三段循环。最大价值是可解释性——打开日志能看到每一步的决策链。代价是每轮多一次 LLM 调用，延迟高。适合中等复杂度、对可观测性要求高的任务，比如客服工单、数据分析。

Plan-and-Execute（流程控制层）：先规划完整计划再逐步执行，中间支持重规划。解决了 ReAct 缺乏全局视野的问题。代价是规划本身消耗推理资源，计划也可能不准。适合步骤多、结构清晰的任务，比如大型代码重构。

Multi-Agent（组织架构层）：多个 Agent 分工协作，每个有自己的角色、工具和知识范围。最大好处是职责分离，每个 Agent 的上下文窗口只需关注自己的范围。适合角色天然分离的场景，比如软件工程的多角色配合。

技术选型三看：

1. 看复杂度：简单→Tool Use，多步推理→ReAct，步骤多→Plan-and-Execute，角色分离→Multi-Agent
2. 看延迟敏感度：实时交互优先 Tool Use 或最简 ReAct
3. 看可观测性需求：ReAct 的循环是天然审计追踪

关键一句：一个 Agent 可以同时用 ReAct + Function Calling，整个系统又可以是 Multi-Agent 架构。选型不是四选一，是在每一层做组合决策。

🎯 记忆辅助：厨房比喻法（四层对应）

想象你是一个厨师，要做一道菜——

一句话口诀： 🗣️

「工欲善其事，边想边做先计划，团队协作顶呱呱」

— 工(Tool Use) → 边想边做(ReAct) → 先计划(Plan-and-Execute) → 团队协作(Multi-Agent)

题3：Agent 的短期/长期记忆怎么设计？写入和检索的策略是什么？#

参考回答（面试口语化）：

记忆系统分三层：

短期记忆就是当前对话的 Context Window。问题是窗口有上限，所以得管——用滑动窗口只保留最近 N 轮，或者用摘要压缩把早期历史缩成一段摘要。

工作记忆是当前任务做到哪一步了、子目标完成情况、已经拿到的中间结果。存在进程内存里，任务结束就释放。

长期记忆是跨会话的，存在向量数据库里。设计的时候要回答三个问题：

什么时候写？ 不是什么都写，浪费空间也增加噪音。触发条件：① 任务完成时（总结经验）；② 用户明确说”记住这个”；③ 检测到关键信息（比如用户偏好、重要配置）。还需要重要性打分+去重，防止重复存储。

怎么检索？ 用户提问时，用语义检索从记忆库召回 top-K 相关片段，再动态注入上下文。但光看相关性不够——还要看时效性，太旧的信息加时间衰减权重。

怎么遗忘？ 记忆库越来越大，检索精度会下降。需要定期做整理：合并相似的记忆、删除过时的、标记不再可信的。

面试追问点 — agent.md / memory.md / skills.md 职责区分？

• agent.md：定义 Agent 的行为规则、系统 prompt（你是谁、怎么做事）
• memory.md：存跨会话的长期记忆（用户偏好、历史关键信息）
• skills.md：注册可复用的能力模块（一组相关工具+prompt 的封装）

题4：RAG 的完整链路是什么？每个环节的关键优化点？#

参考回答（面试口语化）：

RAG 就是给 LLM 外挂一个知识库。完整链路：

1
文档 → 分块(Chunking) → 向量化(Embedding) → 存向量数据库
2
用户提问 → Embedding 查询 → 检索 Top-K → Rerank 重排序
3
→ 注入 Prompt 上下文 → LLM 生成回答

每个环节关键点：

① 分块（Chunking）：这个决定了检索系统的上限。三种主流策略——固定大小滑动窗口（简单通用）、语义分块（按段落自然边界切，适合结构化文档）、递归分块（大块→小块逐级拆，适合长文档）。怎么做？用评估集跑不同策略的效果对比，不能靠感觉。

② Embedding 模型选型：OpenAI text-embedding-3-small/large、BGE 系列（BAAI）、M3E（国产）、Cohere Embed。考虑维度、成本、语言支持、领域适配。

③ 向量数据库选型：Milvus（开源高性能）、Pinecone（云原生）、Weaviate（支持混合搜索）、Chroma（轻量级）、FAISS（本地高效部署）。

④ 检索优化六大手段：分块策略优化、多路检索（向量+关键词BM25+混合）、Rerank 重排序、上下文压缩（只留最相关部分）、查询改写（把用户问题改写成更适合检索的形式）、反馈循环（根据满意度反向调整策略）。

⑤ 常见的翻车原因：召回不足（Top-K 太少或 chunking 不当）、检索到的上下文相关性低、注入的上下文干扰了模型判断、用户问题表述不规范。

题5：怎么减少 Agent 的幻觉？请从多个层面说明。#

参考回答（面试口语化 — 多层防御体系）：

大模型产生幻觉的根本原因是——它是概率语言模型，不是知识库，生成的是”看起来合理”的文本，不保证事实正确。所以缓解策略不能只靠一层，得层层设防。

第一层：Prompt 约束。 最简单但有效。设置 temperature=0 减少随机性，在 prompt 里显式要求”不确定就说不知道”，要求模型引用来源。关键指令放前面，模型更关注开头。

第二层：工具/函数调用。 用精确计算替代模型猜测。比如算数别让模型算，调用计算器工具；查数据别让模型编，调数据库查询。Schema 的 description 写得越清楚，模型越不容易乱来。

第三层：RAG 召回。 给模型提供参考文档，让它基于外部知识回答而不是凭空编造。RAG 做好了对幻觉改善很明显。

第四层：后处理验证。 对模型输出做二次校验——格式解析、静态检查、事实核查。比如生成代码后跑一遍测试，生成结构化数据后做 JSON Schema 校验。

第五层：微调对齐。 用 RLHF/DPO 训练时惩罚幻觉输出，让模型学会说”我不知道”。代价高，一般前三层不够了才上这个。

面试加分：实际生产里一般 RAG + CoT + 对齐训练三板斧一起用，外加工具调用兜底。没有银弹，是系统工程。

题6：会话压缩/上下文管理怎么做？什么时候触发？#

参考回答（面试口语化）：

上下文管理是 Agent 工程最核心的约束——不是算力不够，是装不下那么多信息。

Context Window 里到底塞了什么？ 三块东西：① System Prompt（2000-5000 token，角色设定+行为约束）；② 工具定义（每个工具 JSON Schema 200-500 token，20 个工具就是 4000-10000 token）；③ 对话历史（这个最吃 token，每调一次工具加两条消息，跑 10 轮轻松超 50K token）。

触发时机： ① 当前上下文长度接近模型上限（比如用了 80%）；② 多轮对话中历史信息开始冗余，对当前任务贡献度下降。

压缩方法有三种：

• 滑动窗口：只保留最近 N 轮，老的直接丢。最简单，但容易丢任务目标。
• 摘要压缩（推荐）：用 LLM 把长历史压成摘要。OpenClaw 的 Compaction 四步：分块→逐块摘要→合并摘要→摘要增强。保留三类关键信息——原始任务目标、已完成的关键步骤、当前执行状态和中间产物。
• 关键信息提取：抽实体、动作、意图，丢次要描述。

要避免的坑： token 数不等于字符数，中文 1 个汉字=2-3 token，比英文贵 2-3 倍。不同模型的 tokenizer 不一样，要用实际的模型来校准，留 10% 安全余量。

追问：压缩质量不行/LLM能力不够怎么办？ ——质量审计+重试机制（最多 3 次），检查摘要是否包含决策/待办/约束/待回答/标识符五个章节。实在不行就降级到滑动窗口。

题7：MCP 协议是什么？它的工作原理是怎样的？#

参考回答（面试口语化）：

MCP（Model Context Protocol）是 Anthropic 推出的模型上下文协议，目的是标准化 LLM 和外部工具/数据源怎么交互。你可以理解成 LLM 世界的 USB-C 接口——统一了连接标准。

工作原理：

1
LLM ←→ MCP Client ←→ MCP Server ←→ 外部工具/数据源

架构是客户端-服务端模式。MCP Server 独立运行，通过 JSON-RPC 和 Client 通信。Server 把自己能提供的工具 schema 注册上去，Client 负责发现和调用。最常用的传输方式有 STDIO（本地子进程通信）和 SSE（远程服务端推送）。

MCP vs Function Calling（面试高频对比）：

MCP vs Skill（另一个高频对比）： MCP 是协议层，粒度是一个工具/能力；Skill 是封装好的任务级能力集合。关系上，MCP 可以作为 Skill 内部的调用协议，Skill 可以组合多个 MCP 工具。底层逻辑不同——MCP 关心”怎么调”，Skill 关心”能做什么”。

题8：什么是 Agent？它与普通 LLM 应用的本质区别？#

参考回答（面试口语化）：

Agent 是以 LLM 为大脑，具备自主规划能力、能调用外部工具、拥有记忆系统、可以多步推理循环直至达成目标的智能系统。

和普通 LLM 应用的本质区别从四个维度看：

核心公式： Agent = LLM(Brain) + Planning + Memory + Tool Use

加分比喻： 普通 LLM 是”知识渊博的顾问”——你问他答；Agent 是”能自己干活的员工”——你说”分析报告做成 PPT 发我邮箱”，他自己搞定全过程。

题9：请介绍你做过的一个 Agent 项目（完整叙事）#

参考回答（面试口语化 — 用”四步公式”结构）：

第一步：业务痛点/为什么做？ 我之所以要自己做一个 Code Agent（项目名 pico），有两点考虑。第一是可控性——Claude Code 这类产品对用户是黑盒，prompt 怎么拼的、上下文怎么组装的、工具什么条件下被调用，我都不知道，出了问题没法排查。第二是隐私——实验室项目有保密约束，不能放外部服务，我需要一个能接开源模型的方案。

第二步：初版方案 最开始我做了一套最简单的框架——对接了 GPT 和 Claude 两个后端，注册了 7 类工具（文件读写、代码编辑、命令行、Git 操作、浏览器、API 调用等），用 ReAct 循环驱动。

第三步：踩坑迭代 跑起来才发现问题。最痛的有几个：① 上下文膨胀——长任务跑着跑着 prompt 就爆了，模型开始”失忆”重复操作；② 工具误调用——模型有时候选错工具或传错参数；③ 没有评测——改了东西不知道是好是坏，凭感觉优化。

针对这些做了改进——设计了分层上下文管理与预算裁剪机制，建了结构化记忆系统（任务摘要+文件摘要+会话笔记，分层管理加 freshness 校验），还搭建了标准化工具调用的安全边界（参数校验、工作区隔离、重复调用拦截）。

第四步：量化收益 经过这些优化后：平均 prompt 长度从 6964 压缩到 5418（压缩率 18%，最高 35.63%）；重复读文件次数从 8 次降到 3 次；任务正确率从 66.7% 提升到 100%。现在这套系统有 6 个标准化 benchmark 任务和 86 条自动化测试，每次改动都能跑回归对比。

关键是这个框架：场景 → 问题 → 方案 → 迭代 → 收益，每一步都有数据说话。

题10：Prompt 是怎么构建和优化的？结构化 Prompt 设计原则？#

参考回答（面试口语化）：

Prompt 不是简单写一段话，是结构化、模块化、版本化的工程。

结构上从上到下分六层：

1
1. 系统角色指令（你是谁、要做什么）
2
2. 核心约束（不能做什么、必须遵循什么）
3
3. 工具/技能描述（可用能力的注册）
4
4. 上下文信息（记忆/RAG 检索结果）
5
5. 用户输入（当前轮）
6
6. 输出格式要求

设计原则：

• 关键指令放前面——模型更关注开头和结尾
• 用分隔符明确区分不同信息块（比如---或<system>标签）
• 显式注入约束减少模型”猜”的概率——比如”不确定就说不知道”
• 所有 Prompt 修改版本化管理——改了啥、为啥改、效果如何，都要记录

优化手段：

• Zero-shot → Few-shot（给示例）→ CoT（引导推理）
• 对复杂任务加入 Few-shot 示例
• 对长任务加入更多历史摘要
• 善用温度参数——需要确定性设 temperature=0，需要创造性设高一点

面试加分：Prompt 工程不是”改模板”，而是系统性地理解模型行为，每个改动有依据、有验证。

1
全局上下文 ── 跨会话，不变
2
    ↓ 继承
3
会话上下文 ── 跨多轮，会话级
4
    ↓ 继承
5
单轮上下文 ── 单次交互
6
    ↓ 叠加
7
工具上下文 ── 单次调用，结果可截断

题11：Multi-Agent 架构什么时候需要？通信模式有哪些？#

参考回答（面试口语化）：

什么时候需要 Multi-Agent？ 不是所有场景都需要。当任务复杂度已经超过单个 Agent 的能力边界时才上。具体来说：① 角色天然分离（比如一个写代码、一个审代码、一个测试）；② 单 Agent 上下文窗口装不下所有信息；③ 需要并行处理提升效率。

为什么不能单 Agent 多职能？ 因为职能多了之后，System Prompt 会变得又长又杂，模型容易混淆自己在做什么，工具候选集也会变得太大，影响决策质量。

三种通信模式：

1. Orchestrator（编排器）：一个主 Agent 拆任务、分配、汇总。最简单，适合任务可清晰分解的场景。
2. Peer-to-Peer（对等）：Agent 间平等协商、讨论。适合需要多方辩论达成一致的场景。
3. Hierarchical（层级）：上级管理下级。适合复杂组织结构。

通信方式： 消息队列（Redis/RabbitMQ）、HTTP/RPC、共享存储。一般不直接访问对方记忆，通过消息传递数据，保持模块解耦。

题12：MCP 和 Function Calling 有什么区别和联系？#

参考回答（面试口语化）：

两者本质上是解决同一个问题——让 LLM 调用外部工具，但设计哲学不同。

Function Calling 是模型厂商在 API 层面提供的私有能力——你传一个工具 Schema 列表给模型，模型决定调哪个、传什么参数。各家的格式和细节都不一样，换模型要适配。

MCP 是开放的标准化协议——工具不是内嵌在请求里，而是独立部署在 MCP Server 里，通过 JSON-RPC 和 Client 通信。工具可以动态发现、跨语言、在 Server 级做安全隔离。

联系： 在实际系统里可以同时用——MCP 作为工具接入层屏蔽后端差异，Function Calling 作为模型调用层处理模型交互。也有人用 MCP 客户端封装 Function Calling 的调用逻辑。

题13：MCP 和 Skill 机制的区别是什么？#

参考回答（面试口语化）：

这是两个不同层次的概念。

MCP 是协议层，关心”怎么调”——用标准化的方式让 LLM 发现和调用外部工具。粒度是一个个具体的工具/能力。

Skill 是应用层，关心”能做什么”——是封装好的一个完整能力模块，比如”生成周报”这个 Skill 里可能包含了查数据、分析、格式化、发邮件一系列动作。粒度是一个完整的功能集合。

关系上： MCP 可以作为 Skill 内部的调用协议。一个 Skill 内部可能组合多个 MCP 工具。Skill 是平台特定的（比如 OpenClaw 的 Skill），MCP 是跨平台通用的。

题14：Tool Calling 的完整链路是怎样的？#

参考回答（面试口语化）：

很多人只关注”模型怎么输出 function call”，但实际的完整链路比这长得多：

1
工具注册（定义 Schema） → 候选筛选（工具多时） → 模型决策
2
→ 参数校验 → 执行隔离 → 结果处理 → 结果回传注入上下文

前端工程（模型调用前）：

• 工具注册：为每个工具定义 JSON Schema——name、description、parameters。description 写得好不好直接决定模型会不会正确调用。
• 候选筛选：工具太多时不能一股脑全塞给模型，按任务类型预筛选。一次性加载几十个工具，模型决策质量会下降。
• 模型决策：LLM 根据用户问题+可用工具决定是否调用、调哪个、传什么参数。

后端工程（模型调用后）：

• 参数校验：模型传的参数可能不合法，需要做类型检查+边界校验。
• 执行隔离：工具执行在沙箱里（工作区隔离、权限控制），不能让它随便操作。
• 结果处理：工具返回的结果可能很大（比如读了个大文件），需要截断/摘要。
• 结果回传：将工具结果注入上下文，让模型基于结果做下一步决策。

工具设计原则： 粒度要适中、description 要精心写、不要一次性加载所有工具、独立工具可并行调用。

1
执行 Action → 反思模块评估结果
2
    ├── 结果满意 ✅ → 继续下一步 / 结束
3
    └── 结果不满意 ❌ → 记录错误原因 → 重新规划 → 重新执行

题15：Agent 的评测体系怎么设计？评估哪些维度？#

参考回答（面试口语化）：

一个好的评测体系是区分”做了”和”做好”的关键。我参考了业界实践的四层评测体系：

评估维度（面试常问）：

• 任务完成率：是否达到用户目标
• 步骤效率：花了多少步，有没有走弯路
• 工具调用准确率：选对工具、参数正确
• 幻觉率：编造不存在的信息或工具
• 异常恢复率：出错后能否自己修复
• 人类介入率：多少任务需要人接管

评估方式：

• 离线：benchmark 跑回归，对比优化前后的通过率/耗时变化
• 在线：真实用户留存、反馈、复用率
• LLM-as-Judge：用 GPT-4 或其他模型给回答打分

关键认知：评测不是一次性工作，是持续迭代的闭环——每次翻车 case 都要加进评测集，防止同一个坑踩两次。

1
┌─────────────────────────────────────────┐
2
│           Harness 测试框架               │
3
├─────────────────────────────────────────┤
4
│  ① 评测集管理：题库 + 标签 + 版本控制    │
5
│  ② 执行引擎：批量运行 + 并发控制 + 超时  │
6
│  ③ 结果评估：自动评分 + 失败分类 + diff  │
7
│  ④ 回归报告：通过率/耗时/错误分布对比     │
8
│  ⑤ 合成数据生成：LLM 生成 + 人工校验     │
9
└─────────────────────────────────────────┘

题16：上下文压缩质量不行/LLM 能力不够怎么办？（追问深水区）#

参考回答（面试口语化）：

这是个很好的追问。当你让 LLM 做摘要压缩，但模型本身能力不够、压缩出来的东西质量差，确实是个实际问题。

我的应对策略是质量审计+重试+降级。

质量审计： 摘要做完后做一系列检查——是否包含了任务目标、关键决策、待办事项、执行状态、标识符（文件路径、URL、API key 等）这几个必要模块。如果缺少关键模块，触发生成重试（最多 3 次）。

重试： 每次重试时把审计失败的反馈告诉 LLM——“你上次生成的摘要缺少了 XXX 部分，请补充”。这比简单重试效果要好。

降级策略： 如果重试 3 次仍然不行，降级到更保守的方案——用滑动窗口只保留最近 N 轮对话原文，不做压缩。虽然 token 开销大，但至少信息不丢，比压缩出错误信息强。

OpenClaw 的做法参考： strict 策略要求保留不可重构的标识符（文件名、URL、hash），摘要必须包含 Decisions / Open TODOs / Constraints / Pending user asks / Exact identifiers 五个章节。如果审计失败就重试，每次都把缺失部分指出来让 LLM 补充。

题17：RAG 和微调（Fine-tuning）的适用场景区别？什么时候不该上 RAG？#

参考回答（面试口语化）：

选型逻辑： 需要实时知识、减少幻觉就上 RAG；需要调整模型的”性格”、输出格式、特定能力就微调；两个都要就 RAG + 微调一起上。

什么时候不该上 RAG？ ① 知识变化极快的场景（RAG 的索引还没更新知识就已经过时了）；② 对延迟极度敏感（检索有额外耗时）；③ 模型本身已具备足够的领域知识（不需要外挂知识库）；④ 用户输入太短或太模糊（检索不到相关内容，反而可能引入噪音）。

题18：OpenClaw 的 Compaction 策略的核心流程？#

参考回答（面试口语化）：

Compaction 就是当对话历史太长、简单裁剪（直接丢早期消息）不够用时，用 LLM 把一大段历史压缩成精炼摘要，用摘要替换原始消息。

OpenClaw 的四步流程：

第一步：分块（Chunking） — 按 token 预算把消息切分成多个 chunk（默认 2 段），保留最近 3 轮对话原文不动，只压缩更早的历史。如果单条消息超过窗口 50%，降级处理——跳过这条超大消息，标注”省略”。

第二步：逐块摘要 — 每个 chunk 分别发给 LLM 生成摘要。这一步是并行的，效率高。

第三步：合并摘要 — 再次调用 LLM，把多段局部摘要融合成一份最终摘要。要求保留：任务状态、进度、用户最后请求、决策及原因、待办、约束条件。

第四步：摘要增强 — 追加额外上下文：工具调用失败记录（exit code + error）、文件操作记录、最近几轮原文摘要、从 AGENTS.md 提取的关键规则。

设计理念： 宁可多花 token 调 LLM 做摘要，也不丢关键信息。Compaction 后续的每轮对话都能省大量 token，总开销比不做压缩低得多。

题19：Context Window 里到底塞了哪些内容？为什么容易爆？#

参考回答（面试口语化）：

一次 Agent 请求的 Context Window 里主要塞了三块东西：

1. System Prompt（2000-5000 token）：角色设定、行为规则、输出格式要求。每次请求都得带，是固定开销。

2. 工具定义（4000-10000 token）：每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是这么多。也是固定开销。

3. 对话历史（最吃 token 的部分）：Agent 每调一次工具，history 里就多两条消息——一条 LLM 的 tool_call 请求，一条工具的执行结果。如果工具返回的是整个文件内容，一条消息可能占 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。

为什么容易爆？ 因为这三块加起来会像滚雪球一样越来越大。Agent 运行轮数一多，对话历史不断膨胀。而模型有窗口上限（比如 128K token），一旦超出：要么报错中断任务，要么被迫裁剪导致关键信息丢失，Agent 行为变得不可预测。

OpenClaw 的做法： 设了硬下限 16K token（低于这个值拒绝运行，因为太小了没法正常工作）和软告警 32K token（低于这个值警告可能影响效果）。超出时按优先级逐步处理——先尝试 Compaction 压缩，再尝试截断过大的 tool result，最后才报错建议用户换更大窗口的模型。

题20：System Prompt 在 Agent 系统中承载了哪些职责？越来越长怎么办？#

参考回答（面试口语化）：

System Prompt 在 Agent 系统里至少承载了这几大职责：

1. 角色定义：你是谁、你要做什么、你的能力边界是什么
2. 行为约束：哪些能做、哪些不能做、遇到不确定的情况怎么处理
3. 输出规范：回答格式、是否需要引用来源、结构化输出的要求
4. 工具说明：可用工具有哪些、怎么使用、调用规则
5. 安全护栏：拒绝执行危险指令、敏感信息处理策略

越来越长怎么办？ System Prompt 太长会导致关键指令被稀释，模型抓不住重点。处理策略：

• 模块化管理：按职责拆成独立模块，按需组合注入，不每次全塞
• 分层优先级：核心规则永远保留，次要说明做成可选的”附录”模块
• 外部引用：把长文本（如详细工具说明）存成独立文件，用指令让模型按需读取
• 定期精简：维护 System Prompt 的版本记录，每次迭代都要问”这条规则还必要吗”

🎯 下篇预告：核心模块篇（B+级 · 16 题） — RAG 细节、MCP 深度、多 Agent 协作、工程可靠性