MewCode 项目面试题库

项目基础介绍

1. 简单介绍一下这个 MewCode Coding Agent 项目，先用一两句话讲清楚它是什么，能做什么。

定位：MewCode 是我独立开发的一个终端 AI 编程助手。
功能：用户用自然语言下指令，Agent 自己读代码、改文件、跑命令，整个过程自主完成，不需要人去盯每一步。
架构：底层做了五层架构，支持多家模型厂商的 API，有完整的权限控制和上下文压缩机制，还支持多个 Agent 并行协作。
两点：做这个项目的出发点：每天都在用 Claude Code，但它像个黑盒，想搞清楚 Agent 内部到底怎么决策的，就自己从零造了一个。

2. 你觉得 Agent 有哪些必要元素？

大脑：LLM 理解任务，做判断，决定下一步做什么
手脚：Tool 并非事先编排，而是在循环过程中LLM自主调用工具，目的->为了感受外部环境
循环：原因->任务驱动，和大模型的不同
环境的反馈：是什么：跑命令能看到输出，改代码测试能看到报错->驱动下一轮的决策。没有Agent也不知道做的效果怎么样
不太必要算：安全机制和记忆系统
- 工程上，只是起到好不好用的效果。其他四要素则是决定agent能不能跑
- 这个项目在四要素的基础上做了五层的权限拦截和跨会话记忆

3. Agent 有什么工作模式？

ReAct：Reasoning+Acting 推理->行动->观察
- 灵活，但是token消耗大
Plan-and-Execute：
- 是什么：规划后执行，想清楚完整计划
- 项目参考：Plan Mode ，只读代码，不执行。token消耗少，因为只规划不写、不产生写操作的反复试错（注意不是「只推理一次」，规划阶段照样多轮读文件）
Reflection：
- 是什么：做完再检查：两种审查模式，隐式的反思机制
- 项目参考：额外调一轮Agent，token成本翻倍。测试框架替代
Multi-Agent：Coordinator + Worker
- Coordinator负责拆分任务，Worker在各自独立的Worktree里并行干活，汇总结果

4. 你说 Agent 能自主完成多步任务，那 Agent 怎么知道该停了？万一它一直循环下去怎么办？

Function Calling 协议：看模型是否返回工具调用，不调用则结束。
防止死循环
- 给循环轮次加上一个硬上限
- token用量监控
- 官方做法：
  - 第一层 硬性限制：设置全局最大步数（如 N 步）、单工具的最大重试次数
  - 第二层 重复检测：监控最近N步的工具调用序列，判断是否出现相同工具+相同描述的调用
  - 第三层 收敛性检测：追踪每步的进展指标，判断是否需要重新规划等
  - 第四层建模是否需要外部信息的决策边界
    - 太激进：信息不够则反复进入死循环
    - 太保守：信息没有收集够

5. 你在简历里说独立完成整体架构设计，能简单讲一下分了哪几层、每层做什么？

引擎层：LLM Client、Agent Loop
工具层：内置工具、MCP 等
交互层：CLI、Skill系统等
安全层：危险命令检测、路径沙箱、HITL审批
记忆层：持久化、上下文压缩

Function Calling / 工具调用

6. 你简历写熟悉 Function Calling 协议，能用大白话讲一下这个协议大概是怎么工作的？

本质：模型 → 调用方的一次结构化通信
Agent → LLM：工具列表和对话历史发给大模型，包括工具 name、description、input_schema
LLM → 调用方：名字、调用 id、入参 json（tool_use）
调用方 → LLM：调用 ID（tool_result），再发下一轮请求

7. ReAct 范式能用大白话讲一下吗？它和普通 LLM 调用有啥区别？

是什么：Reasoning + Acting，思考 → 行动 → 反思循环
区别：关键在于状态的延续。LLM 可以看到之前的行为和结果，基于事实决策，而不是凭空生成

如果模型思考是错的应该怎么办？

将工具错误明确标记is_error=True传回给模型，让模型清楚知道刚才哪一步失败了

8. 你的 Agent Loop 一轮里大概会做哪些事？按顺序讲一遍。哪一步容易出 bug？

检查上下文长度 → 超额则压缩（两层压缩机制）
拼装输入：LLM 无状态，每轮都要把决策所需的一切重新打包成一次请求；物理上分三块 —— system、tools、messages
- System Prompt（→ system）：Agent 的角色、行为规则、输出格式
- 工具列表（→ tools）：每个工具的 name / description / input_schema，Function Calling 的基础
- 对话历史（→ messages）：历轮的用户消息、模型回复、tool_use、tool_result，是 Agent「状态延续」的载体
  - 环境信息（→ messages 开头）：cwd、OS、系统时间，让模型知道「跑在哪、什么时间」
  - 项目指令（→ messages 开头）：CLAUDE.md，人手写的项目约定 / 测试 / lint 命令
  - 长期记忆（→ messages 开头）：跨会话的用户偏好与纠正反馈，Agent 自动提取
  - （环境信息 → 项目指令 → 记忆）会话开头一次性注入到 messages 最前面（见第 21 题），之后每轮主要追加新的对话历史和工具结果
调用 LLM → 判断是否返回工具调用
- 不调用：直接结束本轮
- 调用：把模型回复连同工具调用一起塞入历史，进入下一轮
工具调用过程：各种 hook，方便外部扩展
Multi-Agent 场景：轮次开始时检查邮箱，把队友发来的消息拼进历史

容易出 bug

对话一致性：孤儿调用（orphan tool_use）：
- 原因：FC要求有一个结果tool_result。工具执行抛异常没正确返回/ESC中断
- 解决方案：设计对话链校验逻辑，从持久化日志恢复时也会校验，发现孤儿就截断到最近一个完整边界
Multi-Agent：
- 场景描述：Worker A看到WorkerB的消息，商定如何做决定
- 任务重做 / 任务等待的竞态

9. 工具并行执行你是怎么设计的？怎么判断哪些工具可以并行？

可并行（只读不修改外部状态）：ReadFile、Glob（查找文件）、Grep（查找文件内容）
不可并行（写类工具）：WriteFile、EditFile、Bash
spawn 子 Agent 类工具：本身有副作用（创建 worktree、注册任务等共享状态）→ 不能并发，会竞争；但子 Agent 跑起来后是后台异步的，不阻塞主 Agent。并发能力通过 Background 模式实现，不是工具级并发

分批算法：

遍历模型返回的工具调用列表，连续的并发安全工具合并到同一个并发批次，碰到非并发安全工具就开一个新的串行批次
好处：既保证了并发的安全，有保证了工具执行的效率

*追问：两个 ReadFile 读同一个文件，并发会有问题吗？

单次ReadFile是只读IO，并发没有问题

并发批次里有一个工具特别慢，怎么处理？

给每个工具配备独立超时——避免卡住整批
让慢工具流式产出中间状态

10. Plan Mode 是什么？为什么要专门搞这个模式？

是什么：只读规划模式，LLM 只能读文件、grep,glob收集信息，bash也能用但是有限制比如ls、find、git log等不会产生副作用的命令
为什么：自动化执行的边界要交给用户控制，先让用户确认计划再执行，适合复杂多步改动

如何实现Agent按Plan执行

切换权限：Agent规划完成后会调用ExitPlanMode工具，用户在UI上确认同意。系统自动恢复到之前的权限模式，权限层立即生效
工程上
- Plan会自动持久化写到磁盘空间，不怕上下文压缩丢掉
- 退出Plan Mode的时候，完整的Plan文本会通过工具返回值回滚到模型上下文里

Plan Mode如何保证质量

System prompt 的结构化约束
- 模型输出：上下文分析、推荐方案、设计的文件路径、可复用的现有代码、验证方式
Plan出错最常见的原因时没读够代码，Prompt里我强制要求Plan Mode至少调多次工具读相关文件

11. 你的工具系统是怎么注册和分发的？新加一个工具要改多少地方？

工具系统核心是一个字典，key-value，每个工具自己声明：叫什么、是干什么的、入参长什么样、属于读还是写、能不能并发
新加一个工具：写代码继承基类，再把它扔进字典里，剩下的都是自动的
- 工具描述从入参定义里直接推出来
- 权限根据读写命令的设置来定
- 并发分批根据并发设置来定
MCP 工具更省事，配置即生效。启动时连上MCP Server

12. 工具执行结果太大，比如一个 grep 跑出来 50MB 输出，怎么避免塞满上下文？

检查结果大小 → 超过阈值把原始内容写进会话目录下一个专门的工具结果子目录里（文件路径记载）
模型需要完整内容时，自己调用 ReadFile 去读取这个文件
每一轮 Loop 开始时遍历历史，把同一条消息里的工具结果按大小排序处理。根据落盘进行处理

权限与安全

13. 你简历说五层权限拦截，能从内到外讲一遍吗？

起初：最开始只有 HITL 一层，就是每次工具调用都弹框问用户->allow太多
五层（由内到外）：
1. 危险命令检测：只针对 Bash 类工具，正则匹配 rm -rf/、mkfs、fork bomb 等
2. 规则引擎：用户级、项目级、本地级三层规则文件，按 Tool + pattern匹配
3. 路径沙箱：文件类工具，把路径解析成绝对路径，看是不是落在项目根目录里—>防止Agent去改系统级别文件
4. 权限模式：default（正常询问）、acceptEdits（接受编辑）、plan 几种挡位
5. HITL（Human In The Loop）：最外层兜底，人工确认
组合逻辑（三条铁律，最容易被追问）：
1. deny 短路：任何一层判「拒绝」就立刻中断，后面的层无权翻盘（fail-safe，失败朝安全方向倒）
2. allow ≠ 直接执行：某层放行后仍要过后续安全关（规则放行的 Bash，危险命令检测照样拦）
3. HITL 是最后手段：能被规则/模式自动判定的就不打扰人，只有「无人能决定」才落到第 5 层
一个调用的闯关例子（面试时拿这个讲，立刻具体）：
- rm -rf / → ① 直接拦死，到不了后面
- npm test（规则里有 Bash(npm test:*) allow）→ 过 ①、② 放行，不弹框
- 写 ../../../etc/hosts → 过 ①②，③ 沙箱发现跑出项目根，拦
- acceptEdits 模式改项目内文件 → 过 ①②③，④ 自动放行
- default 模式跑没见过的命令 → 一路穿到 ⑤ 弹框问人
加分句：权限拒绝本身会作为 tool_result 回传给模型，让它知道被拦了、换种方式做——呼应 Q43「反馈回路」，用确定性机制兜住模型的不确定性（Harness 思想）

MCP

14. MCP 是什么？为什么不直接把工具写在 Agent 进程里？

是什么：Model Context Protocol，把工具放到独立进程里跑，Agent 通过 MCP Client 连上去，拿到工具列表，代理调用
为什么：配置即生效。用户想加一个新工具，不需要改 Agent 任何代码，编辑一下配置文件指定 MCP Server 启动命令即可

追问：MCP 引入了进程间通信，性能损耗大吗？

IPC 开销完全可以忽略，性能瓶颈在工具实现的内部逻辑

15. MCP 都支持哪些通信方式？

本质：三种传输运的都是 JSON-RPC 2.0 消息，区别只在「Server 跑在哪、走哪条管道」——传输是管道，JSON-RPC 是管道里的内容
1. stdio（标准输入输出）——最常用

Agent 直接把 MCP Server 当成一个子进程启动起来，两边通过标准输入/输出（就是程序间最基本的文本流通道）交换 JSON-RPC 格式的消息。
- 特点：不需要任何网络配置（因为根本没走网络，就是同一台机器上两个进程对话）；Server 的生命周期完全跟着 Agent 走——Agent 退出，子进程也跟着结束。
- 适用场景：本地工具，比如读写文件、代码搜索、git 操作这些天然就在本机执行的任务。
- 优点：最简单、最稳定、延迟极低（微秒级，因为是进程间通信，不走网络）。
2. SSE（Server-Sent Events）

本质上是基于 HTTP 长连接：客户端用普通的 HTTP POST 发请求，服务端通过 SSE（一种服务器持续向客户端推送数据的技术）把消息流式推回来。
- 适用场景：连接已经独立部署在远端的服务，比如公司内部的 RAG 系统、知识库。
- 优点：一个 Server 可以同时服务多个客户端，适合团队共享同一个工具/服务。
- 缺点（追问里提到）：走网络，延迟明显比 stdio 高（几十毫秒起步），还要处理认证、网络抖动、超时重连这些复杂问题。
3. Streamable HTTP

这是 MCP 协议后来新增的，设计目标是逐步替代 SSE。
- 和 SSE 的核心区别：不要求服务端维持长连接。每次请求都是独立的 HTTP 调用，服务端可以灵活选择直接返回普通 JSON，或者按需开一个 SSE 流。
- 优点：对"无状态部署"更友好，比如 Serverless 环境（按需启动、用完即关，不适合维持长连接的场景）。
- 现状：目前生态里大部分 Server 还是用 stdio 或 SSE，Streamable HTTP 还在推广阶段，没完全普及。

16. MCP Server 启动失败，你的 Agent 怎么处理？让 Agent 启动失败还是降级？

降级，不让 Agent 启动失败
MCP 管理器在注册阶段对每个 Server 做异常隔离：成功则连上拉取工具，失败则记录日志
MCP 是扩展能力，不是核心能力，一个 MCP Server 挂掉不应该影响整个 Agent 运行

17. 你简历写"MCP 工具延迟加载，Token 占用减少 85%"，具体是怎么实现的？

原因：Tool 太多，把完整 schema 全部塞进上下文，200k 窗口很快被工具定义挤占，多聊几轮就触发压缩
做法：系统提示词告诉模型「有些工具还没加载，需要先通过 ToolSearch 查询才能调用」，注册时只传名称，不传完整 schema，LLM 按需发现后再加载完整定义

上下文压缩

18. 上下文压缩具体怎么做的？分别什么时机触发？

落盘：大工具结果放到磁盘，不进历史（单结果超50k字符或者一轮工具总和超200k）-> 只留2K预览 + 文件路径
- 开销很低->完整内容调用ReadFile工具去读那个文件即可
全量压缩：每一轮 Loop 检查上轮输入 token 是否超过阈值，超过则调用 LLM 生成对话摘要+边界提示替换旧历史，CLAUDE的做法是上一轮20K+13K这一轮次
- 原因：落盘不够用，上下文依然接近于爆炸，这个时候需要调用LLM自己来生成一份对话摘要
用户主动 compact：用户主动触发压缩命令
- 手动compact的安全余量只有3k

自动压缩后，模型忘了用户最初的需求怎么样

摘要压缩的Prompt里列了9个必须保留的部分：第六项是尽量保留用户的消息原文，prompt里写得是约束语气，本质还是prompt层面的引导

频繁压缩导致的历史对话失真问题

压缩只会替换内存里的对话历史，磁盘里的日志不会更改
用户感知生命周期

19. 摘要本身也要调用 LLM，万一摘要这次调用又超了上下文呢？

预防：压缩触发时，确保剩余 token 余量足够生成摘要不超限
失败兜底：检测上下文长度，丢掉最早的1/5，最多重复三次->三次后触发压缩熔断器，后续就不再自动压缩了

记忆系统

20. 记忆系统怎么设计的？为什么要分层？

用户级：/home下，跨项目的用户偏好、纠正反馈等，如编码风格，命名规范
项目级：.minicoder下/ 项目知识、参考信息，只对当前项目生效
分层原因：不同知识的作用域不同——跨项目的偏好（编码风格等）放用户级，只对当前项目生效的（技术栈、架构约定等）放项目级，避免互相污染
分层
- 工作记忆：200k token就是Agent的大脑带宽，当前正在处理的所有信息总和
- 长期记忆：对应到所有持久化到磁盘的信息
  - 会话持久化：和Agent的每次对话
  - 项目指令文件：预先写好的项目知识和编码规范，
  - 自动记忆：Agent在对话中自动累计的经验

21. 记忆什么时候被注入对话？怎么注入？

注入时机：会话开始或第一次调用时，用一个注入标志位防止重复；压缩之后注入标志重置，下一轮重新注入到摘要后面
- 为什么只注一次：记忆内容固定，每轮都塞是浪费 token + 破坏 prompt cache，所以用布尔标志位，注过就跳过
- 为什么压缩后要重置：上下文压缩会把旧历史（含之前注入的记忆）换成摘要，记忆可能被压没；所以压缩后把标志重置，下一轮重新注入一次、接在摘要后面，保证记忆不丢
注入位置：对话历史开头，环境信息之后
注入顺序：
1. 环境信息（cwd、OS、系统时间）
2. 项目指令（CLAUDE.md）
3. 自动记忆文件内容
4. 一条假装的助手消息：「已了解项目背景和记忆」
  - 为什么要伪造这条：FC 对话是 user/assistant 交替的。前面塞的背景信息以 user 消息出现，若紧接着就是真正的用户问题，就成了「user（背景）→ user（真问题）」两条 user 连着，不自然、易混淆；伪造一条 assistant「收到」把对话补成「user（背景）→ assistant（收到）→ user（真问题）」，给模型一个台阶确认接收背景（Claude Code 同款做法）

Multi-Agent

22. 为什么需要多 Agent？单 Agent 不够用吗？多 Agent 协作有几种模式？

单 Agent 瓶颈：
- 上下文窗口先触顶
- 串行带来的效率低下
多 Agent 适合的场景：任务可拆分且单任务耗时明显
Agent Team 模式：
- 多个 Agent 共享任务清单和邮箱通信，每个 Agent 独立在 Worktree 里跑
- 适合：并行独立推进、不需要频繁协调的场景
Coordinator 模式：
- 一个 Coordinator 统筹，spawn 多个 Worker，自己不写代码，只负责任务拆解和资源协调
- Worker 返回给 Coordinator 的是 XML 格式，更紧凑，对上下文压力更小
- 适合：需要频繁协调的场景
两模式对比（一句话记忆）：

	Agent Team（去中心化）	Coordinator（中心化）
结构	多个平等 Agent	1 个 Coordinator + 多个 Worker
谁分工	共享任务清单，自取	Coordinator 派活，自己不写代码
通信	邮箱互发	Worker 把结果（XML）回给 Coordinator
适合	并行独立、不需频繁协调	需频繁协调、要人统筹汇总

23. 多 Agent 之间用邮箱通信，为什么不用直接调用？

直接调用会出现同步阻塞 → Agent A 调用 Agent B 时整个 Loop 卡住
邮箱模型：
- A 给 B 发消息立即返回，不阻塞；B 在自己的 Loop 里主动消费邮箱
- 消息存储用文件系统，每个消息一个 JSON 文件，天然解耦

工程综合

24. 你做这个 Agent，最大的工程挑战是什么？

多 Agent 协作带来的分布式状态同步
上下文预算管理
- 大结果落盘预览
- 接近上限LLM生成摘要替换历史
- 摘要本身超限时丢最早的轮次重试+熔断
模型的不确定性

25. 你的 Skill 系统是怎么设计的？Skill、MCP、Function Calling 三者是什么关系？

Skill
- 优先级
  - 项目级放在.minicoder/skills
  - 用户级放home目录
  - 内置的打包在代码里
- 执行模式
  - inline模式：Skill的prompt注入当前会话，Agent带着额外指令继续跑
  - fork模式：开一个独立子Agent，有自己的对话历史和过滤过的工具集

inline vs fork 对比（关键追问点）

	inline	fork
怎么跑	Skill 的 prompt 注入当前会话，主 Agent 带着继续	开独立子 Agent 执行
上下文	共用主上下文	自己的对话历史，跑完不污染主上下文
工具	主 Agent 工具集	过滤过的工具集（只给它要的）
适合	轻量、和当前任务连贯	重、独立、想隔离上下文

为什么要 fork：有些 Skill 跑起来产生一堆中间内容，塞主会话会污染上下文 + 烧 token；fork 出去让子 Agent 自己折腾，只把结果带回来——和 Multi-Agent 隔离同思路

Skill、MCP、Function Calling 三者关系（三个层次）

Function Calling：最底层的协议——模型↔工具之间怎么通信（tool_use / tool_result）
MCP：工具的一种来源——把工具放独立进程，最终还是通过 Function Calling 暴露给模型
Skill：最上层的能力封装——打包的是「知识和工作流」，本身不是工具，而是告诉模型「该用哪些工具、按什么步骤做」，按需加载

26. 为什么 Agent 需要工具？没有工具的 LLM 不也能回答问题吗？

感知 -> 决策 -> 行动循环

工具是越多越好吗

工具数量影响模型的选择质量
工具描述的质量比数量更加重要

27. 为什么 Agent 需要记忆？没有记忆不也能完成任务吗？

跨会话的知识延续：用户偏好、纠正反馈、等。每次新会话开始时注入回对话历史
分层原因：因为不同知识的作用域不同。编码风格这种偏好等放用户级、项目的技术栈等放到项目级

CLAUDE.md这种项目指令文件跟记忆有什么区别？

CLAUDE.md这种是人写的项目指令，内容是项目约定和工程规范
记忆则是Agent自动提取的，从对话中抓取用户偏好和反馈，写进记忆文件里

项目对比与补充

28. 你的 MewCode 项目和 Claude Code 相比，核心差异是什么？有什么是你独有的设计？

定位和体量：Coding Agent的每一层架构走通作为目标
生态和精细度：
- CC做了LSP集成、OAuth、MCP官方注册表等。
- CC的上下文管理上有五六层压缩策略针对不同的粒度分别优化。MewCode只做了三层
- CC的工具数量上有50多个覆盖各种垂直场景。MewCode内置了8个核心工具+MCP扩展

29. 自己做 Agent 的时候，踩过最大的坑是什么？

对话历史的一致性问题：
- Fuction Calling的硬约束：每个tool_use块必须有且仅有一个对应的tool_result块，缺了或多了，下一轮API调用直接报错，整个会话崩掉
- 场景：
  - 用户中断
  - 恢复会话
  - 压缩

30. 从开发者的角度，做 Agent 最难的部分是什么？

确定性与不确定性混在一起
- 确定性问题：对话历史的协议合法性，工具分批的并发控制，权限五层的锻炼库
- 不确定性问题：
  - Prompt问题：模型给了错误的参数
  - 工程问题：上下文压缩丢了关键信息导致模型做了错误的决策
  - debug的难题：唯一可靠的方法是回放完整的对话历史，逐轮看模型的推理和工具调用

AI 编程相关

31. 你用的是什么 AI 编程工具？用的哪个模型？

Claude Code —— 跑在终端里，底层用 Claude Opus 4.8（上下文 200K）
- ⚠️ 易错点：1M token 上下文是 Sonnet 的 beta 特性，不是 Opus；版本上也没有「Opus 4.6」（最新 Opus 是 4.8，4.6 是 Sonnet）。按你实际用的模型据实填
加轮次后的工具调用花的tokens数量明显更少

32. 在使用 Claude Code 时候的心得和技巧？

写好CLAUDE.md的重要性：写清楚项目的测试命令和lint命令，让Claude改完代码能自己验证
上下文资源的稀缺性：/clear

33. 如何用 AI Coding 工具从需求到实现全流程？

第一阶段：需求对齐（Chat → Spec）：将需求描述清楚，聊完以后让Claude整理成一个spec文件，确认无误再动手
第二阶段：方案设计（Plan Mode）：需求确认下来就进了Plan Mode出方案，让Claude读完相关代码后出个实施方案
第三阶段：逐步实施（Spec/SDD 模式 + 小步 Commit）：方案完成后，就用Spec模式，先让Claude生成需求规格和任务拆分，按照SDD的方式一步一步推进，改完一步commit一步。每步完成后让Claude自己跑测试、跑lint，通过了再继续

34. 你怎么用 AI 做项目的，全部交给 AI 生成还是每次只提一部分？

三档任务策略

小活（改名/格式/拼写）：直接让 AI 做，无需前戏
中等（加功能/修 bug）：给明确范围 + 验收条件，跑完测试收工
大活（架构/新模块）：三阶段走↓
- 第一阶段·需求对齐（Chat → Spec）：聊清楚需求，让 Claude 整理成 spec 文件，确认无误再动手
- 第二阶段·方案设计（Plan Mode）：进 Plan Mode，让 Claude 读完相关代码后出实施方案，确认后再执行
- 第三阶段·逐步实施（SDD + 小步 Commit）：Claude 生成任务拆分，每个子任务单独一轮，改完自动跑测试 + lint，通过再 commit，commit 完再继续

35. 你怎么保证 AI 写的代码是正确的？

三层质量保障

自动化兜底（Hooks）：测试 + lint 自动跑，拦住大部分明显错误，但拦不住「happy path 写得很对，异常路径漏了」
人工审查（每次改完过 diff）：重点看两个地方——边界条件有没有处理、和现有代码的交互是不是对的
第二个会话审查（关键改动）：写代码的 Claude 已有偏见，换一个全新上下文的视角更容易发现问题

36. Claude Code 有哪些常用命令？

四个高频命令

/clear：每个独立任务前清一次上下文——一个会话里做太多事，后面输出质量会明显下降
/compact：长任务必备，上下文涨到 70% 左右手动压缩一下，可带参数指定压缩时重点保留什么
/plan：复杂任务前进 Plan Mode，Claude 只读不写，看完相关代码出方案，确认后再执行——避免上来就改然后方向跑偏
/rewind：救命用，改完发现不对直接回退到上一个检查点，比手动 git checkout 方便

其他会用到的

命令：/init、/review、/btw、/mcp（非每天必用）
快捷键：Esc 中断、Shift+Tab 切换模式

值得了解的冷门用法

/btw：任务中途想问不相关的问题，用 /btw 问完直接过去，不进对话历史、不影响后续上下文
claude -c：CLI 参数，继续上一个会话
claude -p "task"：非交互模式，可以用在脚本

37. 有没有遇到过 AI 应用或工具无法解决的场景？

两个真实案例

流式 parser 问题：让 Claude 写 OpenAI 兼容协议的流式解析器，单工具调用没问题，一遇到多工具交错 delta 就乱——改了三四版都不对。最后自己画状态机理清路由逻辑，手写核心逻辑，只让 Claude 补边界处理和测试
压缩死循环 bug：压缩丢了关键 tool_result，症状是模型反复调同一个工具，因果链很长，AI 只会在症状位置打补丁——最后自己回放 JSONL 日志逐轮对比才找到根因

AI 搞不定的问题类型

跨多个层面的全局推理
需要隐性知识才能判断的问题（项目背景、历史决策）

这些局限未来能解决吗

能改善：上下文窗口变大、推理能力变强，「因果链长的 bug」会逐步好转
本质问题：隐性知识不是 AI 的问题，是信息没被显式化——把决策背景写进文档、写进 CLAUDE.md，AI 就能用上 → 这也是 Harness Engineering 强调知识库建设的原因

Claude Code 源码相关

38. 介绍一下 Claude Code 主循环 Query 的流程？

整体结构

主循环入口 QueryEngine.submitMessage() → 并行拉取环境信息（系统提示词、CLAUDE.md、git status）拼好上下文 → 进入 queryLoop()
核心是一个 while(true) + state 对象跨轮传递状态，每轮三步：上下文预处理（裁剪/压缩/摘要，防爆）→ 调模型拿流式响应 → 判断有无 tool_use，有就执行工具把结果拼回对话 continue，没有就 break

两个设计细节

Streaming Tool Execution：模型还在流式输出时，前面已完成的 tool_use block 就已经并行执行了，不等整个响应结束——MewCode 实现了同样的思路，多工具场景延迟改善明显
为什么用循环不用递归：递归每轮叠一层帧，长任务几十上百轮有栈溢出风险；循环只在一层帧里跑，内存恒定，也方便断点恢复

终止条件：回复里无 tool_use → break；兜底 maxTurns 防死循环

39. Claude Code 的记忆架构是什么？

两套机制：静态注入 + 动态检索

静态注入——CLAUDE.md 层级加载：从当前目录往上层层遍历，收集各层配置文件全部拼在一起注入上下文：
- 项目根目录 CLAUDE.md、.claude/rules/ 规则文件
- 用户级 ~/.claude/CLAUDE.md、企业全局配置
- 两个额外能力：@include 引入其他文件；paths: frontmatter 条件注入（只有操作到某目录才加载对应规则）→ 让团队把编码规范、架构约定跟代码一起版本管理
动态检索——Auto Memory 系统
- 记忆文件存在 ~/.claude/projects/<slug>/memory/，MEMORY.md 做索引
- 每轮用户输入进来时，异步启动 prefetch，用用户消息跟记忆文件 frontmatter 做相关性匹配，选出最相关几条，工具执行后作为 attachment 注入
- 异步的好处：模型流式输出那段时间刚好把检索做完了，不阻塞主循环
Mewcode的简要实现：每隔几轮用 LLM 提取关键事实存进 auto_memory.json，下次全量注入——记忆条数少时全量反而比相关性检索更简单可靠

为什么用 LLM 做相关性判断而不是向量搜索？

关键词匹配搞不定语义差异（「别用 mock」≠「integration tests must hit a real database」）；向量搜索要维护嵌入索引，记忆文件频繁增删改同步是额外负担；记忆文件通常就几十个，Sonnet 直接读 frontmatter 判断，成本低延迟可控

40. Claude Code 是如何去检索代码之间的相关性的？比如给一个中文需求怎么定位代码？

三个工具的调用
- GrepTool（正则搜内容）
- GlobTool（文件名匹配）
- FileReadTool（读文件）
搜索策略由模型自主决定：直接根据对代码库的理解推理关键词，线索不够就调整策略多轮迭代
大仓库效率：速度不是瓶颈（ripgrep 百万行只需几百毫秒），消耗在模型选关键词的 LLM 调用次数；好处是零预处理、任何语言通用
MewCode 实现：Mewcode标准库实现了简化版 GrepTool，核心思路一致，实测两三轮基本能定位目标代码

Harness 相关

41. Harness Engineering 是什么？

核心公式：Agent = Model + Harness
- Model = CPU，只管算；Context Window = RAM，断电就没；Harness = 操作系统，管调度、权限、I/O；Agent = 跑在上面的应用程序
- 裸模型没有记忆、没有工具、没有执行环境——Harness 就是补上这些能力的工程层
Harness 包含什么
- 知识库（CLAUDE.md 等项目指令文件）
- 工具集成（MCP、CLI）
- 权限约束（allow/deny 规则、沙箱）
- 自动验证（CI、lint、测试）
- 反馈回路（错误信号返回 Agent 让它自我修正）
- 状态管理（跨会话持久化）
核心思想（Mitchell Hashimoto 2026.2 提出）
- 每当发现 Agent 犯了一个错误，就花时间工程化一个解决方案，让这个错误结构上不可能再发生——不是靠 prompt 叮嘱它别犯错，而是从工程上让它犯不了
关键数据
- LangChain 在 Terminal Bench 2.0 上，底层模型不动，只优化 Harness → 得分从 52.8% 飙到 66.5%，排名从第 30 跳到第 5
- 更好的 Harness 往往比更好的 Model 更重要
与传统框架/中间件的本质区别
- 传统框架面对的执行者是确定性的（代码写什么执行什么）；
- LLM 行为是概率性的，prompt 说「不要删除文件」，1% 的情况会忘
- 所以 Harness 必须用确定性工程机制兜底概率性行为——本质是给「不完全可控的执行者」套一套「完全可控的约束系统」

42. 具体描述一下你对 Harness 工程的理解，它与 Context 工程/Prompt 工程的关系？

三者是包含关系，不是并列
- Prompt 在 Context 里面，Context 在 Harness 里面
- Prompt Engineering：管「怎么跟模型说话」，把指令写清楚写结构化——只作用于单轮对话
- Context Engineering：管「给模型什么信息」，通过 RAG、检索、token 排序把正确知识塞进上下文窗口——但有盲区：信息给够了，模型可能拿着信息干危险的事，Context 层没有任何机制拦它
- Harness Engineering：管「整个系统怎么运转」，在模型外围建确定性的约束、反馈和验证，让 Agent 跨多个 context window 都能稳定工作
MewCode 的体感
- 调 prompt 措辞：效果改善有限
- 加权限拦截、错误信息回传、工具输入校验（Harness 层）：Agent 可靠性产生质变
换模型提升天花板，搭 Harness 提升落地能力：用确定性的工程机制把模型的不确定性兜住——Harness 可细化为约束、反馈、验证三层

43. 你这个项目有没有用到 Harness 的思想？

核心理解：Harness = 除了模型本身之外，所有让 Agent 能稳定交付的东西。换模型提升天花板，搭 Harness 提升落地能力。
三个重点模块
- 权限系统：五层权限约束，任何一层 deny 就短路，后面的层不会翻转——不靠 prompt 叮嘱，用工程机制硬拦
- 反馈回路：工具执行失败后结构化告诉模型哪一行出了什么问题、该怎么改；权限拒绝也作为 tool_result 返回让模型调整策略——不光「别跑偏」，还要「出了错能自己爬起来」
- 知识库系统：MEWCODE.md 写项目规范、架构约定、编码习惯，Agent 启动自动加载；Auto Memory 让 Agent 从对话中提取用户偏好和反馈存下来，下次带上——一个是人写的显式规范，一个是 Agent 自动积累的隐式经验，投入产出比最高
其他覆盖的方向
- 上下文管理：两层压缩，大结果存磁盘只留预览，上下文到 80% 触发 LLM 摘要，预留 20K 压缩空间和 13K 当前轮次 buffer
- System Prompt：结构化组装，七个来源三个通道注入，稳定内容走 Prompt Cache，动态信息走 system-reminder 不破坏缓存
- 工具系统：每个工具有元信息标记（只读/可开发），注册中心统一管理，分批执行时根据标记决定并行还是串行
- Agent Loop：四种停止条件兜底（迭代上限、连续异常检测等）
- Hook 系统：工具执行关键节点挂了 15 个生命周期事件，支持自动化 lint、格式化
- 其他：MCP 做 transport 抽象（stdio/HTTP 对上层透明）、会话持久化用 JSONL 追加写入、多 Agent 用 Git Worktree 文件隔离 + 邮箱模式异步通信

Agent 开发实习生八股题库

01 Agent 入门

1. 什么是大模型 Agent？它与传统的 AI 系统有什么不同？

基于LLM的决策：大模型的自回归生成能力进行推理
动态的工具调用：根据任务调用不同的外部工具
上下文记忆：通过上下文窗口或者外部存储维护长期记忆
可拓展性：LLM Agent可以无缝适配不同的任务

2. 🌟【重点】Agent 与 LLM / ChatBot（即 LLM 和 Agent）的本质区别是什么？

目标驱动性：LLM 是被动应答（你问一句答一句）；Agent 是给定目标后自主推进直到完成
自主决策性：Agent 能自己决定下一步做什么、调用哪个工具，LLM 只生成文本
状态持续性：Agent 有记忆和中间状态，能跨多步、多轮维持上下文
一句话：LLM 是"大脑/能力本身"，Agent = LLM + 工具 + 记忆 + 规划 + 循环（Agent Loop），把"会说"变成"会做"

3. 🌟【重点】Agent 和 Workflow（工作流）有什么区别？

Workflow：用预先写好的代码路径把 LLM 和工具串起来，流程固定、可预测（人定流程，模型填空）
Agent：由 LLM 自己动态决定下一步、调用哪个工具，路径不预先固定，靠 Agent Loop 循环推进（模型自己定流程）
控制权差异：Workflow 的控制权在开发者手里，Agent 的控制权交给了模型
取舍：流程确定、追求稳定可控、可预测成本 → Workflow；任务开放、步骤难以提前规划 → Agent（更灵活但更难控、成本和延迟更高）
实践建议（Anthropic 观点）：能用 Workflow 解决就别上 Agent，需要灵活性和模型自主决策时才用 Agent

4. LLM Agent 的基本架构有哪些组成部分？

大脑：LLM，负责推理决策
规划：Planning，任务拆解
工具：Tools，与外部交互
记忆：Memory，短期上下文 + 长期存储
反馈：观察执行结果

5. LLM Agent 如何进行决策？能否使用具体的方法解释？

CoT
典型方法 ReAct：思考 → 行动 → 观察循环，拿真实反馈再决策
Self-Reflection

6. 对比 CoT、ReAct、ToT 的核心差异。

CoT：链式思考，只推理不行动，线性单路径
ReAct：推理 + 行动交替，可调工具拿真实反馈
ToT：树状思考，多路径探索 + 回溯，适合需要搜索的复杂问题

7. 如何让 LLM Agent 具备长期记忆能力？

向量数据库+RAG
分层记忆
- 短期记忆：保留最近的记忆
- 长期记忆：重要的信息进行外部的存储
预训练+知识图谱

8. LLM Agent 如何进行动态 API 调用？

通过 Function Calling：把 API 封装成工具，给出 name / description / 参数 schema
LLM 根据需求生成结构化调用参数（JSON）
执行后把结果返回 LLM，继续下一轮决策

9. LLM Agent 在多模态任务中如何执行推理？

用多模态模型（VLM）统一编码图像 / 音频 / 文本
或调用专用工具（OCR、ASR、图像识别）把结果转成文本再交给 LLM
LLM 在统一上下文里融合多模态信息做推理

10. LLM Agent 主要有哪些局限性？

幻觉、输出不可靠
长程任务易跑偏、误差累积
上下文窗口有限、成本高、延迟大
缺乏真正的规划与可解释性

11. 端到端 LLM 规划 vs 模块化 Agent 架构在长程任务中的瓶颈。

端到端：一次性生成完整计划，长程下误差累积、无法及时纠错
模块化：规划 / 执行 / 反思解耦，可局部纠错，但模块间协调成本高
共同瓶颈：上下文长度、状态一致性、错误传播

12. 除 ReAct 外的推理-行动范式有哪些？

Plan-and-Execute：先规划完整计划再逐步执行
Reflexion：执行后自我反思、改进重试
ToT / Graph of Thoughts：多路径搜索 + 回溯
Self-Ask、Least-to-Most 等分解式范式

13. 🌟【重点】Agent 有什么工作模式（编排范式）？

一、单 Agent 内部的推理范式

ReAct：推理 → 行动 → 观察循环，最常用
Plan-and-Execute：先规划完整计划，再逐步执行
Reflection / Reflexion：执行后自我反思、改进重试
ToT / GoT：树/图状多路径搜索 + 回溯

二、Workflow 编排模式（Anthropic《Building Effective Agents》总结）

Prompt Chaining：链式拆解，前一步输出喂给下一步
Routing：先分类，再路由到不同处理分支
Parallelization：并行执行多个子任务后聚合
Orchestrator-Workers：协调者拆任务派给多个 worker，再汇总
Evaluator-Optimizer：生成 → 评估 → 改进的闭环

三、多 Agent 协作模式

中心化：Coordinator + Worker（主管派活）
去中心化：任务独立、Agent 平等协作

14. 为什么我们要使用 SDK 进行 Agent 开发？

封装模型api调用
提供统一接口调用不同模型，同时封装了认证，参数格式，流式输出等

15. tokenizer 是什么？

把文本切分成 token（模型最小处理单元）并映射成 id
常见算法：BPE、WordPiece
直接影响上下文长度计算和调用成本

02 关于主流 Agent 框架

16. 主流的 Agent 编程框架你知道哪些？

LangChain / LangGraph、LlamaIndex（外部数据结合，RAG）
AutoGPT（最早的自主任务循环 Agent，单体而非多 Agent）、BabyAGI（最小化的自主Agent）、CrewAI（多个Agent组成团队协作）、AutoGen、MetaGPT

17. 你为什么要用 LangGraph，而不是写一个普通 Python pipeline？

LangGraph 用图描述状态流转，天然支持循环、分支、条件路由
内置状态管理、检查点、可中断恢复
普通 pipeline 是线性 DAG，难表达 Agent 的循环和回退

18. 市面上有哪些主流的 LLM Agent 框架？各自的特点是什么？

LangChain：组件丰富、生态大；LangGraph：图式编排、可控
LlamaIndex：偏 RAG / 数据接入
CrewAI / AutoGen：多 Agent 协作
MetaGPT：SOP 驱动的多角色协作

19. LangChain 的核心组件有哪些？

Models：OpenAI、Anthropic、本地LLM
Prompts Templates：用户创建动态提示词，提高泛化能力
Memory：
- 短期记忆：存储对话上下文
- 长期记忆：结合向量数据库持久化存储
Chains：链式调用
- Simple Chains：单步任务
- Sequential Chains：串联多个步骤
Agents：通过ReAct
Tools：工具，访问API，Google搜索

20. LangChain Agent 的主要类型有哪些？

ReAct / Zero-shot-ReAct：LLM直接决定工具调用，不使用额外的提示信息
Conversational（带记忆的对话型）：结合会话记忆
Structured Chat Agent：适用于结构化对话，如表单填充等
Self-Reflective Agent：具备自我反馈机制，可修正错误回答

21. 什么是 LangChain 中的提示模板（Prompt Template）？

预定义的文本结构

22. 什么是 LangChain 中的链（Chain）？

把多个组件（Prompt → LLM → 解析器）串成一个可调用流程

23. 什么是 LangChain 中的记忆（Memory）？

在多轮对话中保存历史并注入下一轮 Prompt
类型：Buffer、Window、Summary、向量检索记忆
解决 LLM 本身无状态的问题

24. 如何为 LangChain Agent 添加新的工具？

用 @tool 装饰器或继承 BaseTool，定义 name / description / 参数
把工具加入 tools 列表传给 Agent
description 要写清楚，直接影响调用准确率

25. LangChain Agent 如何处理复杂的多步骤任务？

通过 Agent Loop：思考 → 选工具 → 执行 → 观察，循环到完成
复杂任务可先 Planning 拆解再逐步执行
借助 Memory 维持中间状态

26. 解释 LangChain 中的"思考-行动-观察"循环，并讨论其在复杂任务解决中的作用。

Thought（推理下一步）→ Action（调工具）→ Observation（看结果），循环往复直到得出答案
作用：让模型基于真实反馈纠错，而非凭空生成，减少幻觉
适合需要外部信息、多步推进的复杂任务

27. LangChain Agent 如何确保输出的安全性和合规性？

输入 / 输出过滤，敏感词与内容审核
工具权限限制、人工确认（HITL）
结构化输出校验、Guardrails 约束

28. 如何评估 LangChain Agent 的性能？

任务成功率、步数、token / 成本、延迟
工具调用准确率、轨迹（trajectory）质量
用 LangSmith 做 trace 与评测、LLM-as-Judge 打分

29. LlamaIndex 如何与 LangChain 结合？

LlamaIndex主要是用于增强LangChain的外部数据访问能力

数据索引：预处理文档，将内容存入向量数据库
增强检索RAG：LangChain调用LlamaIndex进行查询
存储方式：支持FAISS、ChromaDB、Weaviate等

30. AutoGPT 如何实现自主决策？

给定目标后自主循环：生成任务 → 执行 → 反思 → 生成新任务
用记忆和工具持续推进，无需每步人工介入
缺点：容易跑偏、成本高、可控性差

31. BabyAGI 如何进行任务管理？

维护任务队列，按优先级取任务执行
执行后由 LLM 生成新任务并重排优先级
三个核心：执行 Agent / 任务创建 Agent / 优先级 Agent

32. CrewAI 如何管理多个 Agent 之间的协作？

定义角色（Role）、目标、任务和协作流程
Agent 间按流程（顺序 / 层级）协作
支持任务委派和共享上下文

33. LangChain 如何支持 API 调用？

把 API 封装成 Tool（如 RequestsTool 或自定义工具）
或用 OpenAPI / Functions 让 LLM 生成调用参数
Agent 在 Loop 中按需调用并消费返回结果

03 RAG

34. 🌟【重点】什么是 RAG？

Retrieval-Augmented Generation，检索增强生成
先从外部知识库检索相关内容拼进 Prompt，再让 LLM 生成答案
解决知识过时、幻觉、私有数据无法覆盖的问题；无需重训即可更新知识、可溯源

35. 🌟【重点】RAG 的整体工作流程（技术架构）是怎样的？

离线（建库）：文档加载 → 分块 Chunking → Embedding 向量化 → 存入向量库
在线（问答）：Query 改写 → 向量化 → 检索 Top-K（常配合 BM25 混合检索）→ Re-rank 重排 → 拼上下文 → LLM 生成（带引用溯源）
一句话：检索 + 重排决定上下文质量，生成决定表达——“garbage in garbage out”，检索质量是上限

36. 🌟【重点】RAG 和微调（Fine-tuning）各自的区别？什么场景用哪个？

RAG：往上下文"注入外部知识"，不改模型参数；适合知识频繁更新、需要溯源、私有数据接入；成本低、上线快、可减少幻觉
微调（含 PEFT / LoRA）：改的是模型"能力 / 风格 / 领域适配"，把知识"焊进参数"；适合固定领域风格、格式遵循、知识相对稳定
类比：RAG 像"开卷考试给资料"，微调像"考前把知识背进脑子"
实践常组合：微调补能力 + RAG 补知识

37. RAG 常见的应用场景和数据源有哪些？

场景：企业知识库问答、智能客服、文档 / 代码助手、搜索增强、带依据的推荐解释
数据源：PDF / Word / Markdown / 网页；数据库 / API / 知识图谱；代码库、表格数据

38. 🌟【重点】RAG 中的文档切割（Chunking）策略有哪些？如何权衡？

为什么要切：适配上下文窗口、提升检索精度（粒度更细）
常见策略：固定长度切分、按语义 / 结构切（标题 / 段落）、重叠切分（overlap）、父子块（小块检索、大块喂模型）、加 metadata
权衡：块太小 → 语义不完整、检索碎片化；块太大 → 噪声多、稀释相关信息、浪费 token
解决"切断语义"：重叠 + 父子块 + 语义切分

39. 在实际工程中，如何验证 Chunking 的质量？你会用哪些指标？

看检索召回率、答案正确率是否随分块策略变化
抽样人工检查块的语义完整性
A/B 对比不同分块策略的端到端指标

40. 🌟【重点】Embedding 有哪几种算法 / 类型？如何选 Embedding 模型？

发展脉络：
- 静态词向量：Word2Vec、GloVe、FastText（一词一向量，不区分上下文）
- 上下文相关：BERT 系（Sentence-BERT）、双塔 / 对比学习训练的句向量
- 主流商用 / 开源：OpenAI text-embedding-3、BGE、M3E、GTE、Cohere Embed 等
选型看：任务领域、语言、向量维度、最大长度、成本
评估：参考 MTEB 榜单，再用自己业务数据测召回率 / 命中率、相似度区分度、推理速度

41. 🌟【重点】Re-rank（重排）是什么？为什么需要？

召回为了快，常用双塔 / 向量近似检索，精度有限、会带回不够相关的块
Re-rank：在召回 Top-N 之后，用更强的 Cross-Encoder（把 query 和文档拼一起算相关性）重新精排，取 Top-K 给 LLM
作用：召回保"广"（高召回），重排保"准"（高精度），两段式提升上下文质量
常用：BGE-Reranker、Cohere Rerank 等

42. 🌟【重点】什么是多路召回（混合检索）？具体怎么做？

多路召回：同时用多种检索方式各取一批候选再融合，互补"字面"与"语义"
- 向量检索：语义相似（换种说法也能命中）
- BM25 / 倒排：关键词精确匹配（产品型号、专有名词、缩写）
- 可加：知识图谱、父子块、Query 扩展 / HyDE
融合：用 RRF（倒数排名融合）或加权求和合并多路结果，再做 Re-rank
去冗余：MMR（最大边际相关）兼顾相关性与多样性，避免 Top-K 全是高度相似的重复内容
权重：没有固定值，关键词敏感 → BM25 权重高，用验证集调参

43. 🌟【重点】什么是向量数据库？如何做技术选型？

是什么：专门存储和检索高维向量的数据库，用 ANN（近似最近邻，如 HNSW / IVF）做相似度检索，支持元数据过滤
选型维度：数据规模、QPS、召回精度、是否需元数据过滤、部署方式（自托管 / 云）、成本、生态
常见对比：
- Milvus：功能全、适合大规模生产
- Qdrant：Rust 实现、性能好、过滤强
- Weaviate：模块化、原生支持混合检索
- pgvector：复用 Postgres、运维简单、规模中小
- Faiss：是库不是服务、本地高性能、需自己包一层

44. 🌟【重点】Query 改写是什么？为什么要做？一般怎么做？

为什么：口语化 / 含指代 / 太短的 query 直接检索效果差
怎么做：
- LLM 改写：指代消解、补全上下文、拆分子问题
- 同义词 / 实体扩展
- HyDE：先让 LLM 生成"假设答案"，再用它去检索（向量更接近文档）
效果：显著提升召回质量

45. RAG 如何在多轮对话中保持上下文？

把历史对话纳入 query 改写（指代消解、补全）
多轮记忆 + 当前 query 一起参与检索
维护会话状态，必要时摘要历史

46. 🌟【重点】怎么量化 / 评估 RAG 的效果？

检索侧：召回率、命中率、MRR / NDCG
生成侧：忠实度（faithfulness）、答案相关性、正确性
工具：RAGAS 等 + 人工 / LLM-as-Judge
排查思路：先分清是"检索没召回"还是"召回了但生成错"

47. 🌟【重点】什么是大模型幻觉？怎么降低幻觉？

是什么：模型生成看似合理但与事实不符 / 无依据的内容（参数化知识有限、过时，按概率"编"出来）
降低方法：
- RAG：给真实依据 + 要求"基于检索内容作答"、给引用溯源
- 约束：结构化输出、让模型"不知道就说不知道"
- 校验：用工具 / 外部数据二次核验、多源交叉验证、置信度过滤
- 模型侧：换更强模型、降低 temperature、必要时微调
注意：RAG 能显著减少但不能根除幻觉（检索错 / 读错也会答错）

48. RAG 有哪些局限性？对效率有何影响？

受限于检索质量：检索不到就答不对；多跳推理弱、长文档整合难
引入检索 + 更长上下文 → 延迟、成本上升
可用缓存、精简上下文、混合检索 + 重排来优化

49. RAG 系统有问题，一般如何排查和解决？

分段定位：先判断是检索召回问题还是生成问题
检索结果不含答案 → 查分块 / embedding / query 改写
含答案但答错 → 查 Prompt / 模型 / 上下文顺序

50. 当 TPS 高的情况下，RAG 系统很容易崩，是模型容量不够吗？

不一定是模型容量；瓶颈常在检索链路（向量库、Embedding 服务、网络）
高并发下检索排队、显存 / 连接耗尽更先暴露
解法：缓存、限流、批处理、扩容、异步化

51. 如果小说长度远超上下文窗口，怎么回答其中的问题？

分块索引 + 检索相关片段（RAG）
分层摘要（map-reduce）逐层压缩
复杂问题做多跳检索 + 迭代回答

52. RAG 如何保证信息新鲜度？如何处理偏见和错误信息？

新鲜度：定时 / 增量更新索引、文档加时间戳、检索时按时间加权或优先返回最新版本
质量：把控数据源、清洗审核；引用溯源让用户可核验；多源交叉验证、置信度过滤

53. 点积（没有归一化）和余弦相似度的使用场景分别是什么？

余弦：只看方向、忽略模长，文本相似度常用
点积：同时受方向和模长影响
向量已归一化时两者等价，此时用点积更快

54. 用过哪些开源 RAG 框架（比如 RAGFlow）？如何选择合适场景？

RAGFlow、Dify、LangChain、LlamaIndex、Haystack
选型看：要开箱即用产品 vs 灵活自定义编排
RAGFlow 文档解析强；LlamaIndex 检索灵活；Dify 偏低代码平台

04 MCP / Function Calling

55. 🌟【重点】Function Calling（函数调用）是什么？

让 LLM 具备"调用外部函数/工具"能力的机制：把工具的 name、description、参数 JSON schema 告诉模型
模型在推理时判断要不要调用、调用哪个，输出结构化的调用请求（tool_use：工具名 + 调用 id + JSON 参数）
调用方实际执行函数，把结果（tool_result）拼回上下文，模型据此继续下一步
本质：模型 ↔ 程序之间的一次结构化通信协议，让"会说话的模型"具备"会动手"的能力（感知→决策→行动闭环的关键一环）

56. 🌟【重点】MCP 是什么协议？

MCP = Model Context Protocol（模型上下文协议），Anthropic 提出的开放标准
作用：统一"模型/Agent ↔ 外部工具、数据、资源"的连接方式，被称为"AI 应用的 USB-C 接口"
解决的问题：每个工具都要为每个框架单独适配的 M×N 难题 → 标准化后变成 M+N
三大角色：Host（宿主应用，如 IDE/Agent）/ Client（连接器，与 Server 一对一）/ Server（暴露 Tools、Resources、Prompts）
底层：基于 JSON-RPC 2.0，传输支持 Stdio / SSE / Streamable HTTP
与 Function Calling 关系：MCP 是工具的标准来源/接入层，工具最终仍通过 Function Calling 暴露给模型

57. MCP 与"函数调用/工具调用"有何关系？

MCP统一了工具与资源的“发现于描述”
实践：MCP暴露企业的api之后，Agent框架等可以通过MCP客户端适配层复用这些工具

58. Tool Calling 的核心机制是什么？

工具注册：name、description、参数JSON schema
识别意图：LLM在推理过程中判断是否需要调用工具，以及调用哪个工具。模型输出一个结构化对象（JSON）
参数解析与校验
安全执行：沙箱环境中执行工具调用，设置超时、权限和资源限制
结果注入

59. 举一个例子来说明 MCP 和 Function Calling 的区别。

查天气：FC 是在代码里写死 get_weather 函数并注册给模型
MCP 是把 weather 能力做成独立 Server，任何 Agent 配置即可接入
FC 是应用内绑定，MCP 是跨应用复用的标准接口

60. 20+ 工具场景下的工具选择决策维度有哪些？

工具描述清晰度、命名区分度
按需加载 / 检索，减少无关工具干扰
分组、分层，用 router 先粗选再精选

61. 如何防止工具调用的无限循环？

第一层硬性限制：设置全局最大步数（如 N 步）、单工具的最大重试次数
第二层重复检测：监控最近N步的工具调用序列，判断是否出现相同工具+相同描述的调用
第三层收敛性检测：追踪每步的进展指标，判断是否需要重新规划等
第四层建模是否需要外部信息的决策边界

62. MCP 工具很多，全部塞给大模型可能导致内存池过大的问题，处理方法？

延迟加载：只注册名称，按需通过检索加载完整 schema
工具分组 / 命名空间隔离
按场景动态挂载需要的 Server

63. MCP 的核心角色有哪些？

Host：宿主应用（如 IDE、Agent）
Client：连接器，与 Server 一对一
Server：提供工具 / 资源 / 提示

64. MCP Server 能暴露哪些能力？

Tools：可执行操作
Resources：可读数据
Prompts：提示模板

65. MCP 与传统 REST / gRPC 的区别是什么？

MCP 面向 LLM，自带工具发现、schema 描述、提示等语义
REST / gRPC 是通用 RPC，需自己包装给模型
MCP 标准化了"模型↔工具"的交互层

66. 什么是"结构化输出（Structured Output）"？

让模型按指定 schema（如 JSON）输出
便于程序解析和下游处理
实现：JSON mode、Function Calling、约束解码

67. MCP 典型落地场景有哪些？

接数据库 / 文件系统 / API
接企业内部系统、第三方 SaaS
给 IDE / 桌面 Agent 扩展能力

68. MCP 与 OpenAI/Claude 等厂商的函数/工具生态关系？

MCP 是开放标准，厂商 FC 是各自实现
MCP 工具可被代理成厂商的 tool 定义
互补：FC 负责模型侧，MCP 负责工具侧标准化

69. MCP 的消息/接口是如何组织的？

基于 JSON-RPC 2.0
请求 / 响应 / 通知三类消息
初始化握手时协商 capabilities

70. 资源（Resource）与工具（Tool）的边界是什么？

Resource：只读数据，由应用决定何时读取（如文件内容）
Tool：可执行动作，由模型决定调用，可能有副作用
区别在"读 vs 做"和"谁触发"

71. 提示（Prompt）在 MCP 中的作用？

Server 提供可复用的提示模板
用户 / 应用可显式调用（如 slash command）
标准化常用交互流程

72. 结构化输出的协商方式是什么？

工具定义 input / output schema
初始化时协商双方 capabilities
支持返回结构化内容块

73. 会话/上下文如何跨工具调用传递？

由 Host / Agent 维护对话历史
工具结果以 tool_result 拼回上下文
Server 端一般无状态，状态留在 Client / Host

74. 服务能力（Capabilities）是什么？客户端如何发现/列举资源与工具？

初始化握手时双方声明支持的能力
通过 tools/list、resources/list 列举
列表变化时发通知更新

75. 日志与通知在 MCP 协议中的角色？

日志：Server 向 Client 上报运行信息，便于调试
通知：单向消息（如列表变更、进度）
提升系统可观测性

76. 是否支持图片/二进制内容？支持哪些传输？

支持文本和二进制（图片等）内容块
传输方式：Stdio、SSE、Streamable HTTP

77. 何时选择 Stdio？何时选择 Streamable HTTP？

Stdio：本地子进程，低延迟、部署简单
Streamable HTTP：远端 / 无状态部署，Serverless 友好
取决于部署位置和是否需要远程访问

78. 连接稳定性与超时重试如何设计？

设超时、重连、指数退避
异常隔离：单 Server 挂掉不影响整体
健康检查 + 降级

79. 如何在 Python 中定义一个最小化 FastMCP 服务器？

创建 FastMCP 实例
@mcp.tool() 装饰函数即注册为工具
mcp.run() 启动（默认 stdio 传输）

80. 工具的输入/输出如何结构化？

用类型注解 / Pydantic 定义入参
返回结构化内容或文本
框架自动生成 JSON schema 给模型

81. 如何为 Tool 提供进度与日志？

通过 Context 对象上报进度（progress）
用 ctx.info / debug 输出日志
长任务分阶段反馈

82. Prompt 的最佳实践？

参数化、职责单一
清晰命名和描述
复用常见工作流

83. 工具幂等性与重试策略？错误处理与用户提示？

写操作尽量幂等（带 id / 去重）
失败明确返回 is_error，让模型感知
区分可重试 / 不可重试错误，给清晰提示

05 Agent 进阶以及实际应用

84. 如何设计一个完整的 AI Agent 系统？

四要素：LLM（大脑）+ 工具 + 记忆 + 规划
加上 Agent Loop、权限 / 安全、可观测（日志 / trace）
按场景选单 / 多 Agent，定义工具集与评测

85. 常见的提示词优化方法有哪些？

明确角色、任务、输出格式
few-shot 示例、CoT 引导
结构化分区（指令 / 上下文 / 约束）、迭代调优

86. Prompt 注入是什么？有哪些攻击方式？如何防护？

用户 / 外部内容注入恶意指令，劫持模型行为
方式：直接注入、间接注入（污染检索内容 / 网页）
防护：指令与数据隔离、输入过滤、权限最小化、输出审查

87. 上下文窗口怎么设计？如何降低 token？怎么评测设计的质量？

设计：分区（系统 / 历史 / 检索 / 工具），保留关键、裁剪冗余
降 token：摘要、检索注入、工具结果落盘、延迟加载
评测：任务成功率、token 用量、关键信息保留率

88. 工具描述该怎么写能提升调用准确率？

名称语义化，描述讲清"做什么、何时用、何时不用"
参数 schema 清晰，给约束和示例
工具间边界明确，避免功能重叠

89. 如果做一个 Agent，遇到工具调用失败或者 LLM 幻觉怎么办？

工具失败：明确标 is_error 回传，让模型重试或换路
幻觉：用工具拿真实数据校验、要求引用、结构化约束
加重试上限、人工兜底

90. ReAct 实际怎么落地？提示词怎么设计？

提示里规定 Thought / Action / Observation 格式
提供工具列表与调用规范
框架解析 Action 执行，把 Observation 拼回，循环

91. 如何衡量 LLM Agent 的性能？

任务成功率、轨迹质量、步数
延迟、token / 成本
工具调用准确率、鲁棒性

92. 如何优化 LLM Agent 的性能？

模型选型 + 提示优化
上下文裁剪、缓存、并行工具
流式输出、小模型分流、规划减少无效步

93. Agent 服务的高可用是怎么保证的？

多副本、限流、降级、熔断
依赖（模型 / 向量库）超时重试与隔离
监控告警、灰度发布

94. 性能优化：LangGraph 的多 Agent 协作会带来延迟，如何通过流式等方式优化？

流式输出 token，先返回再继续
工具并行、节点并发执行
缓存中间结果、减少串行依赖

95. 构建 Agent 有哪些最佳实践？

从简单开始，能用单 Agent 就不上多 Agent
工具描述清晰、系统可观测、可评测
加边界（权限 / 轮次上限），持续迭代优化

96. LLM Agent 在企业应用中的典型场景有哪些？

智能客服、知识库问答
流程自动化（RPA + LLM）
数据分析、代码 / 运维助手

97. Agent 在实际应用中面临哪些挑战？

可靠性 / 幻觉、成本与延迟
安全与权限、评测困难
长程任务稳定性

98. 怎么做 Agent 的权限管理？

工具级权限、最小权限原则
规则引擎 + 危险操作检测
HITL 人工确认、沙箱隔离

99. 如果单一智能体的提示词过长，导致性能下降，如何将其拆分为多个智能体？

按职责 / 领域拆分，每个 Agent 提示精简
主 Agent 负责协调、分发子任务
子 Agent 各自独立上下文，减少干扰

100. 单 Agent 输出不可靠时的鲁棒性保障机制有哪些？

结构化输出校验 + 重试
自我反思 / 多次采样投票
工具校验、人工兜底

101. 单 Agent 和 Multi-Agent 你什么时候选哪个？怎么协作？

任务简单 / 串行 → 单 Agent
可拆分、需并行或不同专长 → 多 Agent
协作：共享任务清单 + 消息通信 / 主从协调

102. 多 Agent 相比单 Agent 有什么优势？如何选择？

优势：突破单上下文、并行提效、专业分工
代价：协调复杂、状态同步难
选择：收益大于协调成本时才用

103. 介绍一下多 Agent 系统的角色分工、通信与冲突协调。

分工：按角色 / 专长（规划、执行、审查）
通信：消息 / 共享内存 / 黑板模式
冲突协调：协调者仲裁、加锁 / 任务隔离

104. 中心化协调 vs 去中心化协作的适用条件？

中心化：需强一致、频繁协调 → Coordinator 统筹
去中心化：任务独立、并行推进 → Agent 平等协作
看协调频率和一致性要求

105. Multi Agent 子 Agent 需要把哪些信息传递给主 Agent，哪些没必要传？

传：任务结果、关键结论、状态 / 错误
不传：中间推理细节、冗长过程日志
原则：紧凑结构化，减轻主 Agent 上下文压力

106. Multi-Agent 如何实现团队协作？

共享任务清单 + 邮箱 / 消息通信
每个 Agent 独立工作区（如 Worktree）
通过协调者或自组织推进

107. 拆分多 Agent 之后，链路失败或局部失败时怎么处理？

局部重试、超时、降级
失败隔离，不拖垮整体
协调者感知并重新分配 / 兜底

108. 多 Agent 场景下，上下文传递为什么用 JSON / Slot 这类结构化方式？

结构化更紧凑、无歧义、易解析
减少上下文体积和误解
便于校验和路由

109. 多 Agent 的上下文污染怎么解决？

各 Agent 上下文隔离，只传必要信息
用结构化接口而非整段历史
清晰边界 + 摘要压缩

110. Planning 有哪些方法可以实现？分别讲一讲。

任务分解（Decomposition）：拆成子任务逐个解决
Plan-and-Execute：先出完整计划再执行；ReAct：边做边规划
ToT / 反思迭代、层级规划

111. Agent 的 Memory 你怎么设计？

短期：对话历史 / 工作记忆（上下文）
长期：向量库 / 文件持久化 + 检索注入
加摘要、分层（用户级 / 项目级）

112. 你在写 Agent 的时候有用过长期记忆和短期记忆吗？

短期：当前对话上下文，存近期交互
长期：跨会话偏好 / 知识，持久化到外部存储
两者配合：短期负责工作，长期负责沉淀

113. Agent 短期记忆如何转化为长期记忆？

触发条件（重要 / 重复 / 用户指定）下提取
摘要成事实 / 偏好写入持久化存储
下次按相关性检索注入

114. 你觉得短期记忆里会存储 Function Call 的内容吗？如果不放进短期记忆会有什么问题？

会，tool_use 和 tool_result 都要留在历史
不放：模型不知道调过什么、拿到什么结果
后果：重复调用、配对断裂、上下文不一致

115. 如何界定短期记忆和长期记忆的边界，以及这两个记忆的存储方式还有存储什么？

短期：当前会话相关，存上下文窗口 / 内存
长期：跨会话有价值，存数据库 / 向量库 / 文件
内容：短期存对话细节，长期存提炼后的事实 / 偏好

116. 长上下文场景下的外部记忆增强机制有哪些？

向量检索（RAG）按需调取
摘要 / 分层记忆
落盘 + 引用、KV 缓存

117. 用户偏好是怎么得来的？

显式：用户直接设置 / 反馈
隐式：从历史行为 / 对话中提取
持久化并在相关场景注入

118. 记忆摘要的触发机制应考虑哪些指标？

上下文 token 占用 / 轮次
信息重要性 / 重复度
成本与延迟阈值

119. 意图识别阶段 Query 改写可能把关键信息改丢，你怎么发现这种问题？

对比改写前后语义 / 实体是否丢失
监控召回率下降、答非所问
加校验：保留原 query 做兜底检索

120. 如果记忆信息和当前聊天上下文冲突，你们怎么处理？以谁为准？

一般以当前对话 / 最新信息为准
记忆作为背景参考，冲突时降权
必要时向用户确认

121. 请介绍几个目前行业内广泛使用的 LLM 综合性基准测试，并说明它们各自的侧重点。

MMLU：多学科知识；GSM8K / MATH：数学推理
HumanEval：代码生成；HellaSwag：常识推理
MT-Bench / Chatbot Arena：对话与人类偏好

122. 什么是"LLM-as-a-Judge"？使用 LLM 来评估另一个 LLM 的输出，有哪些注意事项？

用强 LLM 给另一个模型输出打分 / 比较
注意：位置偏见、长度偏见、自我偏好
缓解：随机顺序、明确评分标准、多次投票

123. 你了解哪些专门用于评估 Agent 能力的基准测试？这些基准通常如何构建？

如 AgentBench、WebArena、GAIA、SWE-bench
构建：真实任务 + 可验证的成功判定
覆盖工具使用、多步推理、环境交互

124. 评估一个 Agent 的任务完成情况时，除了最终结果的正确性，还应该看哪些维度？

效率（步数 / token / 时间）
鲁棒性、安全合规
轨迹合理性、成本

125. 如何持续监控和评估一个已经部署上线的 LLM 应用或 Agent 服务的表现？

采集 trace、token、延迟、错误率
采样 + LLM-as-Judge 评质量
Bad case 回流、告警、定期评测

126. 不同 Agent 架构差别比较（单体/分层/多 Agent）。

单体：简单直接，复杂任务上下文吃紧
分层：规划 / 执行解耦，可控但有协调成本
多 Agent：并行专业分工，状态同步复杂

127. 项目中 Agent 执行一个进程有哪几种方式？

前台同步执行
后台异步 / Background 模式
子进程 / 子 Agent spawn

128. 什么时候使用图数据库或知识图谱来增强或替代传统的向量检索？

需要多跳关系推理、实体关联时
结构化、关系密集的领域知识
与向量检索结合做 GraphRAG

129. 如何选取使用具体哪个大模型？

看任务难度、上下文长度、成本、延迟
能力（推理 / 代码 / 多模态）匹配场景
闭源强但贵，开源可控可私有化；先评测再定

130. 知识图谱数据如何构造？

实体 / 关系抽取（规则 + LLM）
schema 设计、实体对齐去重
存入图数据库，持续更新维护

06 Agent 实际场景题

131. 你是如何利用 LangSmith 或类似工具进行 Trace 跟踪，定位 Agent 在哪一步出问题的？

全链路记录每步：输入、思考、工具调用、输出
定位：是检索没召回 / 工具参数错 / 模型决策偏
结合 token、延迟、错误标记逐步排查

132. 你监控了哪些指标？

质量：成功率、工具调用准确率、Bad case 率
性能：延迟（首 token / 端到端）、token / 成本
稳定：错误率、超时、重试次数

133. 你怎么设计的 Agent 循环执行？

while 循环 + 状态对象跨轮传递
每轮：拼上下文 → 调模型 → 判断有无工具调用 → 执行回填
终止：无 tool_use 或达 maxTurns

134. 多 Agent 架构：每个子 Agent 的模型选型是什么？为什么要这么选？

简单 / 高频任务用小快模型（省成本、降延迟）
复杂推理 / 规划用强模型
按任务难度分级，平衡效果与成本

135. System Prompt 怎么设计的？

角色定位、能力边界、行为准则
工具使用规范、输出格式
分区清晰、精简、必要约束

136. 端到端的延迟是多少？（肯定是不短的，只是好奇 Agent 方向的延迟）

取决于轮数 × 单轮（模型推理 + 工具）时间
多步 Agent 通常几秒到几十秒
优化：流式、并行工具、缓存、小模型分流

137. 你们是如何分析 Bad Case 的？

收集 + 分类（检索 / 工具 / 模型 / 提示问题）
回放 trace 定位根因
闭环：修提示 / 加规则 / 补数据，回归验证

138. Bad Case 闭环处理：“当用户说我睡不着，想听恐怖故事”（非法请求），Agent 怎么处理？

先判断意图与安全边界
不生硬拒绝，可共情 + 引导（讲轻松内容助眠）
涉违规明确拒绝并给替代方案

139. 手机里有个 Chatbot，我跟他说帮我点一份外卖，那么这个时候只有 Function A，那这个 Agent 该怎么处理？

能力不匹配时不能硬调 Function A
坦诚告知做不到，或用 A 能覆盖的部分
必要时引导到正确渠道，避免幻觉式乱调

140. 如果让你设计一个点外卖 Agent，你会怎么设计？【美团真题】如果用户说"随便"，Agent 怎么处理？

组件：意图理解 + 槽位填充 + 推荐 + 下单工具
“随便”：用历史偏好 / 热门 / 场景推荐，给 2-3 个选项让确认
主动澄清而非瞎下单

141. 如果让你设计一个千问点奶茶的 Agent，你如何设计？

槽位：品类、规格、糖度、温度、加料
多轮澄清补全槽位 + 推荐
调下单 API，确认后提交

142. 请设计一个 LLM Agent，用于医学问答，它需要具备哪些关键组件？

权威知识库 + RAG（可溯源）
安全审查、免责声明、不替代诊断
意图识别，敏感场景转人工 / 就医提示

143. 关于对话历史，为什么要保留最近 20 轮对话，而不是 10 轮、30 轮？

平衡上下文完整性与 token 成本 / 延迟
太少丢上下文，太多噪声 + 贵 + 降智
20 是经验折中，可配合摘要保留更早信息

144. 如何构建一个 AI 照片助手，能够对用户上万张照片进行索引，并根据用户描述检索？

用多模态模型给图片生成 embedding / 标签
存向量库，支持以文搜图
加元数据（时间 / 地点）过滤，增量索引

145. Prompt 怎么知道效果好不好，怎么调优？

用评测集 + 指标（准确率 / 格式合规）
A/B 对比、case 分析
迭代：加约束 / 示例 / 调结构

146. 对大模型进行提示时有没有它的输出不符合指令的现象，是怎么解决的？

明确格式要求 + few-shot 示例
结构化输出 / JSON mode 约束
输出校验，不合规则重试

07 Skills

147. Skills 相比于传统 Agent 好处在哪里？工具 Skills 和产品 Skills 如何理解？

好处：能力按需加载，不占满上下文，可复用、可组合
工具 Skills：封装具体操作能力
产品 Skills：封装某产品 / 领域的方法论、规范和输出模板，偏业务任务

148. 🌟【重点】什么是 Skills？

把领域知识 / 工作流打包成可被 Agent 按需加载的能力包
核心是 SKILL.md + 脚本 / 参考资料
渐进式披露，用到才加载

149. Skills VS MCP：从工程视角理解差异；上下文管理策略的本质差异；互补而非竞争：Skills + MCP 的混合架构。

MCP：连接外部工具 / 数据（连接协议）
Skills：注入知识与流程（指导模型怎么做）
互补：MCP 给能力，Skills 给方法，可混合架构

150. 🌟【重点】Function Calling、MCP、Skills 三者有什么区别？

Function Calling：最底层的通信协议——规定模型↔工具之间怎么对话（tool_use / tool_result）
MCP：工具的一种标准来源/接入方式——把工具放到独立进程/服务，通过标准协议接入，最终仍通过 Function Calling 暴露给模型
Skills：最上层的能力/知识封装——打包的是"知识 + 工作流"，告诉模型"该用哪些工具、按什么步骤做"，渐进式按需加载
一句话：FC 是地基（怎么通信），MCP 是标准插座（从哪接工具），Skills 是说明书（教模型怎么把工具组合起来干活）
三者是分层、互补关系，不是竞争

151. Skills 的主要组成部分：SKILL.md 是什么？references/ 是什么？scripts/ 是什么？assets/ 是什么？四件套配合起来的样子。

SKILL.md：技能的工作手册
references/：参考资料；
- api doc等
- style-guide.md
- troubleshooting.md
scripts/：可执行脚本；
- python脚本/shell脚本：解析pdf/发邮件/查天气
assets/：模板 / 资源
- ppt模板，logo
- 字体，图片等

152. Skills 的渐进式加载机制：第一层元数据（Metadata）；第二层技能主体（Instructions）；第三层附加资源（Scripts & References）；渐进式披露的效果：从 16k 到 500 Token。

一层元数据：name + description，常驻、占用极小
二层指令主体：命中后才加载 SKILL.md
三层附加资源：用到才读 scripts / references → 整体从一次性 16k 降到约 500 token

153. 大模型如何理解一个 Skill 的好与不好，Skill 该如何做评测？

看是否在该用时被正确触发、用对
评测：触发准确率、任务成功率、对比有无 Skill
收集 bad case 迭代 description 与内容

154. Skills 实战案例——员工分析 SQL 查询：技能文件结构；SKILL.md 核心内容示例；技能的使用效果。

文件结构：SKILL.md + 表结构 references + 查询脚本
SKILL.md 核心：说明何时用、库表 schema、SQL 规范
效果：模型按规范生成正确查询，少出错

155. skill_creator：使用案例。

一个用来创建 Skill 的 Skill
引导用户描述需求，自动生成 SKILL.md 与目录结构
降低手写 Skill 的门槛

156. 你自己有手搓过哪些 Skills？

可举：代码审查、提交规范、项目专用查询 / 部署流程
动机：把重复工作流和团队规范沉淀成 Skill
强调评测与迭代（按真实经历作答）

08 开放性问题 & 前沿知识

157. 平常会用 Vibe Coding 吗？使用过哪些工具？有哪些经验总结？

用过，如 Claude Code / Cursor
经验：明确需求、小步迭代、及时审查
不盲信，关键逻辑自己把关

158. 你觉得使用 AI Coding 工具后，程序员应该更关注的点是哪些？【美团】

需求拆解、架构设计、问题定义
代码审查与质量把关
系统思维、领域知识，而非纯敲码

159. 平常 AI Coding 时，如何减少 token 用量？

精准上下文、按需提供文件
及时 /clear、/compact
复用规则文件（CLAUDE.md），避免重复解释

160. 怎么让 AI Coding 工具符合团队的代码规范，减少幻觉？

把规范写进 CLAUDE.md / 规则文件
提供示例和约束，让它先读现有代码
测试 + 审查兜底

161. SDD 了解吗？

Spec-Driven Development，规范 / 规格驱动开发
先写清晰规格 / 设计再让 AI 实现
减少跑偏，便于验证

162. 怎么接触 AI 前沿知识的？

论文（arXiv）、官方博客、技术社区
Twitter / X、GitHub trending
动手复现 + 实践

163. 哪些可以看最新模型榜单的地方？

LMArena（Chatbot Arena）、OpenLLM Leaderboard
各 benchmark 官网、SWE-bench
厂商发布与第三方评测

164. Codex 上下文窗口过大后降智了怎么办？

及时压缩 / 清理上下文
拆任务、分多个会话
只给相关上下文，避免噪声

165. 如不知道最近的 Harness Engineering，结合具体场景讲讲。

围绕模型搭的"脚手架"：上下文、工具、记忆、反馈、约束
让模型在真实任务里稳定发挥
场景：把项目知识 / 流程 / 规则喂给 Agent 提升可靠性

166. 🌟【重点】什么是 A2A 协议？

A2A = Agent-to-Agent Protocol，Google 于 2025 年提出的开放协议（后捐给 Linux 基金会），用于不同 Agent 之间互相通信、协作
解决的问题：不同厂商/框架做的 Agent 彼此孤立，A2A 让它们能跨平台发现、对话、协同完成任务
核心概念：
- Agent Card：用 JSON 描述 Agent 的能力、地址、认证方式（通常放在 /.well-known/agent.json，用于"发现"）
- Task：A2A 以任务为单位，支持长任务、流式更新和状态同步
- Client Agent / Remote Agent：发起方与执行方
底层：基于 HTTP + JSON-RPC 2.0，流式用 SSE
与 MCP 的区别（高频）：MCP 解决"Agent ↔ 工具/数据"的连接；A2A 解决"Agent ↔ Agent"的协作，两者互补，常一起用

167. 如果现在用 Harness Engineering，你的 Agent 项目会怎么做？

完善上下文工程（记忆 / 规则 / 检索）
强化工具与反馈闭环、可观测
把隐性知识显式化进知识库

168. 如何看待 AI 的发展？如何不被 AI 淘汰？

AI 是放大器，替代重复劳动
提升不可替代能力：判断、设计、跨域整合
学会用 AI、驾驭 AI

169. 如果用 AI Coding 来重做项目，你会怎么做？

先理清需求与架构（Spec / Plan）
模块化、小步迭代 + 测试
用规则文件约束、关键处人工把关

170. Claude Code 的 Memory 三层逻辑设计，为什么这么设计？

用户级（跨项目偏好）、项目级（项目知识）、本地级
分层匹配作用域，避免污染、便于共享与版本管理
按需注入，控制上下文成本

171. 未来 LLM Agent 可能有哪些技术突破？

更强长程规划与记忆
更可靠的工具使用与自我纠错
多模态、具身、低成本与可控性

172. 平常使用 AI 吗，都用来干嘛？如果我想使用 AI，比如 Coding 领域，你有何建议？

编码、查资料、写作、总结
建议：从小任务上手、明确需求、审查产出
边用边学原理，别当黑盒

173. Cursor 如果上下文过长有没有性能下降的现象？千问的上下文窗口多大？

会，过长会注意力稀释 / 降智，应精简上下文
千问（Qwen）多数版本支持 128K，长上下文版本更大
实际看具体型号

174. 对于 Agent 未来 to C 和 to B 在技术和架构上觉得未来可能会有什么发展？

to C：个人助理，强调体验 / 隐私 / 个性化
to B：流程自动化，强调可靠 / 安全 / 集成
架构上 to B 更重权限、审计、私有化

175. 你认为当前 LLM 距通用人工智能（AGI）还有多远？最关键的缺失能力是什么？

仍有距离，难给确切时间
缺：可靠推理 / 规划、持续学习、真正理解与因果
自主性与可信度仍不足

176. 你如何看待开源模型和闭源模型生态系统的竞争与共存？

闭源领先能力，开源追赶且可控可私有
长期共存、互相促进
选型按场景：能力 vs 成本 / 可控

177. 具身智能（Embodied AI），即 LLM 与机器人的结合，被认为是 AI 的下一个浪潮。你认为 LLM 将如何赋能机器人？

当"大脑"做高层理解、规划、指令分解
结合感知与底层控制
挑战：实时性、安全、物理世界泛化

178. 了解过哪些模型吗？

闭源：GPT / Claude / Gemini
开源：Llama、Qwen、DeepSeek、Mistral
按能力 / 成本 / 场景选型

179. 你认为目前限制 Agent 能力和普及的最大瓶颈是什么？

可靠性 / 幻觉，长程稳定性
成本与延迟、安全与信任
评测与可控性

180. 你对大模型时代的 AI 安全怎么看？

内容安全（有害 / 偏见）、对齐问题
隐私与数据安全、滥用风险
Prompt 注入等新型攻击，需纵深防御

181. 个性化是 LLM 应用的重要方向。在实现高度个性化的 Agent 或助手的过程中，我们应如何平衡效果、隐私和安全？

数据最小化、本地 / 脱敏处理
用户可控（授权 / 删除）
分层存储 + 权限，在效果与隐私间权衡

182. 展望未来 3-5 年，你认为 LLM 和 Agent 技术最有可能在哪个行业或领域率先实现颠覆性应用？为什么？

软件开发、客服、内容创作较快落地
原因：数字化程度高、可验证、ROI 明显
言之有理即可

183. 你如何看待 Agent 领域的"涌现能力"？我们应该追求更强大的基础模型，还是更精巧的 Agent 架构？

二者都要：强基础模型是上限，精巧架构是发挥
当前阶段架构 / Harness 工程能显著提效
长期靠模型能力突破

09 OpenClaw

184. 🌟【重点】什么是 OpenClaw？（用过吗？写过 Skills 吗？）

开源的通用型 Agent（智能体），把"模型 + 工具 + 记忆 + Skills + MCP"这套 Harness 工程做成了开箱即用的产品
定位：用自然语言驱动 Agent 自主完成多步任务（写代码、查资料、操作文件 / 浏览器等）
作答提示：用过就举真实例子（写过哪些 Skill、接过哪些 MCP）；没用过则讲对其机制的理解

185. 🌟【重点】OpenClaw 的核心亮点是什么？

开源 + 开放生态：Skills（能力包）+ MCP（接外部工具）可自由扩展、社区共建
Harness 工程成熟：上下文工程、记忆、工具反馈闭环、权限 / 安全做得完整
渐进式能力加载：Skills 渐进披露，用到才加载，省上下文
模型能力到位 + 工程打磨：体验好、可自托管、数据可控

186. 🌟【重点】OpenClaw 与传统 Agent 有什么区别？

传统 Agent（如早期 AutoGPT）：流程脆弱、容易跑偏、生态封闭、扩展难
OpenClaw：以 Harness 为核心——强调上下文工程 + Skills / MCP 开放生态 + 文件式记忆
可扩展性：能力按需挂载（Skills / MCP），而不是把所有逻辑写死在代码里
工程化：完整的权限、可观测、上下文压缩，长程任务更稳

187. 🌟【重点】OpenClaw 的记忆机制是怎么实现的？

分层 + 文件式（markdown）记忆：
- 短期：当前会话上下文，超长就上下文压缩 / 摘要
- 长期：写进项目级 / 用户级 markdown 记忆文件，新会话开始时注入
作用域分层：项目级（放仓库、团队共享约定）vs 用户级（个人偏好）vs 内置
与项目指令文件（类 CLAUDE.md）区别：指令是人写的工程规范；记忆是 Agent 自动从对话里提取的偏好 / 反馈
知识多时配合向量库 / RAG 召回相关记忆

188. OpenClaw 到底解决了什么痛点？为什么爆火？

痛点：之前 Agent 要么能力弱、要么闭源 / 不可控、要么扩展难，落地体验差
解法：开源可自托管（数据可控）+ 生态可扩展（Skills / MCP）+ 工程成熟（稳定可用）
爆火时机：模型能力到位 + Harness 工程成熟 + 开源社区共建，正好凑齐

189. 🌟【重点】OpenClaw 有什么缺点？为什么那么烧 token？

烧 token 的原因：
- Agentic Loop 多轮"思考-行动-观察"，每轮都带着完整上下文重复进模型
- 大系统提示 + 工具定义 + 记忆 / 检索内容长期占用上下文
- 多工具结果、长文件内容回灌上下文，越滚越大
其他缺点：成本 / 延迟高、长程任务仍会跑偏、对模型能力依赖强、自主执行命令的安全性需兜底
缓解：上下文压缩、Skills 渐进加载、按需挂载工具、缓存、及时清理上下文

190. OpenClaw 的文件目录结构是怎样的？

大致：配置文件（模型 / 权限 / MCP 配置）+ skills/（每个技能一个目录，含 SKILL.md、scripts/、references/、assets/）+ markdown 记忆文件 + 项目指令文件
优先级：项目级放仓库目录、用户级放 home 目录、内置打包在代码里
（以实际使用版本为准，作答时结合自己跑过的目录讲）

191. Coze、n8n 和 OpenClaw 的区别在哪里？

Coze：字节的低代码 Agent / Bot 搭建平台，可视化、偏 SaaS，上手快但灵活性 / 可控性有限
n8n：通用工作流自动化（iPaaS），节点编排、确定性流程，不以 LLM 自主决策为核心
OpenClaw：代码级、开源，以 LLM 自主决策 + Skills / MCP 生态为核心，更灵活、可自托管，但更吃工程能力和 token
一句话：n8n 是"固定工作流"，Coze 是"低代码搭 Bot"，OpenClaw 是"开源自主 Agent"

MewCode 项目学习

初识 Coding Agent
让 AI 开口说话
工具系统
让 Agent 自己干活
System Prompt 设计
权限系统 —— 给 Agent 装上安全刹车
MCP 协议 —— 开放式工具生态
上下文管理 —— 当 Token 开始烧钱
记忆系统 —— 跨会话的 Agent 记忆
Slash Command —— 内置命令框架
Skill 系统 —— 可复用的技能包
Hook 系统 —— 生命周期钩子与自动化
SubAgent —— 子 Agent 与任务分发
Worktree —— Git 工作树并行开发
Agent Teams —— 从一次性子任务到长期协作团队
回顾与展望 —— 从一个空壳到一支团队

1. 初识 Coding Agent

用户：通过自然语言下命令

2. 让 AI 开口说话

做什么：完成模型接入，让 CLI 能接收用户输入、调用大模型并流式展示回复。
怎么实现：抽象统一的模型 Provider 和消息结构，处理鉴权、模型配置、流式事件、错误与重试。
关键设计 / 取舍：统一接口与厂商特性的平衡；流式输出与非流式输出的差异；配置和密钥如何安全管理。
面试追问点：一次模型请求由哪些消息组成？流式响应如何拼接？如何适配不同模型服务？网络异常和限流如何处理？

3. 工具系统

工具描述决定工具使用的质量：
- 例如：1. 做什么；2. 什么时候使用；3. 什么时候不该使用；4. 参数约束；5. 返回格式；6. 与其他工具如何配合。大文件可先用 Grep 定位，再用 ReadFile 读取指定范围。
工具接口设计不能只有名字和执行方法：
- 用 JSON Schema 描述参数，让模型能够稳定地产生结构化调用。
- 执行结果和错误都要结构化返回，因为错误也是 Agent 后续决策的有效信息。
- 抽取通用基础实现，避免每个工具重复处理校验、超时、截断和日志。
- 不同语言中采用各自惯用的接口与错误处理模式。
工具注册中心：通过统一的 toAPIFormat() 遍历所有启用工具，把名称、描述和入参 Schema 转换成模型 API 所需格式；同时负责工具查找、启停和执行分发。

4. 让 Agent 自己干活

Function Calling：告诉模型怎么来调用工具
- 告诉模型有哪些工具：通过tools参数来告诉模型工具的列表（每个工具有名字、描述、参数格式）
- 模型决定调用工具role:assistant：他会在回复里输出一个结构化的请求，想调哪些工具，参数有哪些——tool_use
- 进行工具的执行role:user，把结果告诉模型：tool_use->tool_result返回给模型
- 模型继续
Agent Loop：用户输入 → 模型决策 → 执行一个或多个工具 → 将 tool_result 回填消息历史 → 模型继续判断，直到输出最终答案。
循环终止条件：模型不再请求工具、达到最大轮数、用户取消、出现不可恢复错误，或权限系统拒绝关键操作。
关键设计 / 取舍：并行工具调用的收益与冲突风险；工具结果顺序和 tool_use_id 配对；如何避免死循环与重复调用。
面试追问点：完整的一轮 Agent Loop 怎么走？模型为什么知道该调用哪个工具？多个工具能否并行？如何处理中断、超时和失败？

5. System Prompt 设计

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

6. 权限系统 —— 给 Agent 装上安全刹车

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

7. MCP 协议 —— 开放式工具生态

由哪些部分构成：
- 运行时的角色
  - Host: 真正的AI应用本体
  - Client: Host里的一个连接组件，负责和某一个Server建立连接、发送请求、接收相应。可声明支持的能力
    - Root: 告诉Server当前项目的工作目录
    - Stampling 允许Server反过来请求Host调用LLM
    - Elicitation:允许Server请求Host追问用户额外信息
  - Server: 对外暴露能力的程序，有可能在本地or远程
- 协议层
  - Data Layer层：定义消息长什么样，怎么列工具、调用工具等等——JSON-RPC 2.0
    - Request: Client->Server id,method,params
    - Response: Server->Client id,result,error
    - Notification: 通知不需要响应 method
  - Transport Layer：定义消息怎么在两边传过去
    - stdio: 项目启动一个子进程来运行MCP Server。然后通过这个子进程的stdin和stdout的管道来通信，消息是UTF-8编码的JSON-RPC消息
      - stdout:读取相应 JSON-RPC 推送给Host
      - stderr:调式日志，不参与协议。负责调试与排查
    - Streamable HTTP: 依靠HTTP请求post给远程Server，然后Server返回json相应
      - Accept声明：application/json,text/event-stream
MCP双方提供什么东西
- Tools：暴露一组工具（名字、描述和参数的JSON Schema）。项目的工具在进程内执行，MCP的tool使用则是在外部工具中执行
- Resources：可读取的数据源：url/name/mimeType等。有点类似RAG中的上下文源
- Prompts：预定义提示词模板，是由工具定义方提供
一次完成的MCP会话
- 初始化握手：Client<->Server 请求和回应声明协议版本，支持的能力，身份的信息
- 工具发现：Client发送tools/list请求，获取Server提供的所有工具定义
- 工具调用：Client决定使用某个MCP工具时，Client发送tools/call请求
项目的具体做法
- 请求——响应的异步：使用map来管理等待中的请求，id号进行匹配
- 工具包装：适配器模式，MCP工具包装成Tool接口（设计模式）
- Host可以连接Server列表：用户配置。yaml中（项目级/用户级）
- 完整流程
  - 1. 启动：读取配置文件获取MCP Server列表
  - 2.选择Transport 根据Server配置
  - 3.后台连接：启动时异步连接所有配置的Server
  - 4.初始化：发送initialize+notifications
  - 5.工具发现：tools/list
  - 6.包装注册：MCPToolWrapper,注册到ToolRegistry，也就是适配器模式
  - 7.Agent使用：Agent决定是否调用MCP工具
  - 8.工具调用：Agent调用->MCPToolWrapper.execute->MCP Client->MCP Server
  - 9.结果返回: MCP Server返回结果->MCPToolWrapper转换->Agent处理
- 工具延迟加载：
  - 1.MCP工具注册时标记自己为延迟工具 MCPToolWrapper.ShouldDefer() = true
  - 2.Agent Loop每轮生成工具列表时跳过延迟工具的完整schema，只列名字
  - 3.模型看到名字列表，先调用ToolSearch拉取完整的定义
  - 4.在客户端的Registry里找到工具，返回完整schema，标记为已发现

8. 上下文管理 —— 当 Token 开始烧钱

目的：让Agent在有限的Token窗口里长时间工作

两层压缩（自动）
- 大结果落盘：原因（工具结果超阈值）预防
  - 单个结果超出阈值50KB：完整结果写磁盘文件，对话历史放预览+文件路径，ReadFile读取该文件即可
  - 每条消息的聚合限制：每个工具都是40k,加起来超过了200k。超过聚合限制的最大结果集已被存盘，剩余结果合计大小低于限制200k
  - 幂等写入：文件名tool_use_id，而且用wx模式写入（文件已存在则跳过）防止每一轮重写同样的文件
  - Prompt Cache
    - 原理：新一轮请求的消息列表前缀和前一轮完全一样，api可以跳过前缀部分的处理。cache持续命中，则处理增量，如果cache反复失效，每轮都要重新处理几万甚至十几万token前缀
    - 决策冻结（项目做法）：系统维护一个ContentReplacementState，记录每个tool_use_id的替换决策。seenIds,replacements
      - 已替换过的：缓存的预览字符串原样重放
      - 已决定不替换的：永远保留原文，不再评估
      - 正常评估是否需要替换，做出决策后冻结
- 全量压缩兜底
  - 触发时机：第一层落盘不够用了，上下文仍然接近爆炸，调用LLM自己来生成一份对话摘要，替换旧消息依旧20k对话历史+13k预留空间
  - 为什么是写死固定值13k：
    - 因为ReadFile工具读取的内容都是那么大，buffer要防止的风险是下一轮突然多了一个大工具结果，这个风险取决于单次工具结果有多大，和总窗口无关
    - 防止两次检查之间一个意外偏大的工具结果出现把上下文撑爆
  - 预留的20k给摘要输出
    - 9个的结构化部分
  - 摘要Prompt设计
手动/compat

9. 记忆系统 —— 跨会话的 Agent 记忆

工作记忆：200k token就是Agent的大脑带宽，当前正在处理的所有信息总和
长期记忆：对应到所有持久化到磁盘的信息
- 会话持久化：和Agent的每次对话
  - 存储格式：JSONL格式（role,content,timespan）。好处：追加写入、奔溃安全、增量加载
  - 文件组织：.minicoder/sessions/yyyymmdd-hhmmss-xxxx 后缀随机防止冲突
  - 会话管理器：一个SessionManager进行管理，他维护.minicoder/sessions/目录，提供所有会话操作的入口，进行会话的创建、恢复、列表、删除
    - 恢复会话：
      - 逐行解析JSONL：逐行读取，遇到解析失败则跳过
      - 验证消息链完整性：JSONL文件可能因为崩溃而截断。所以需要追踪未完成的工具调用-tool_result
      - 检查token量，如果恢复的会话很长，token量可能已经超过压缩阈值，进行压缩
      - 插入时间跨度prompt: 上次会话是什么时候，中间可能有代码变更，建议重新读取相关文件
    - 过期会话清理：sessions目录会堆积大量的旧会话文件。超过30天没有活跃的会话，在启动时会自动清理。会话列表按照最后活跃时间倒序排列
- 项目指令文件：预先写好的项目知识和编码规范，
  - 优先级排列：项目级->.minicoder级别->用户级。流程：检查文件->—分割线拼接->system-reminder注入到messages中
  - @include:如果所有指令都在minicoder.md中会变得很臃肿，比如一个微服务项目，每个服务的编码规范可能不一样，让他可以在minicoder.md中引入其他文件的内容
- 自动记忆：Agent在对话中自动累计的经验
  - 用户偏好：用户的编码习惯和风格要求
  - 纠正反馈：用户明确指出的反馈
  - 项目知识：当前项目的具体技术信息
  - 参考信息：外部链接和资料（API文档等）

10. Slash Command —— 内置命令框架

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

11. Skill 系统 —— 可复用的技能包

是什么: 写给Agent的SOP（标准操作流程）
- 面试回答：最上层的能力封装——打包的是「知识和工作流」，本身不是工具，而是告诉模型「该用哪些工具、按什么步骤做」，按需加载
- Anthropic的定义：【把专家经验、操作流程和最佳实践打包成可复用的能力】
- 特点：一致性（行为一致）、知识固化（定下的规范）、跨平台复用
- 和Slash Command
  - 相同点：都是把一端固定的Prompt模板交给Agent来执行，而且prompt经过精心设计后质量会更加稳定
  - skill：把prompt从源码搬进独立的markdown文件，任何用户都能新增和修改
  - Skill自动注册成命令：遍历所有的skill，在Slash中心新建一个【PROMPT】类型指令，命令名取frontmatter里的name，描述取description+【skill】
Skill设计
- Md文件：yaml方便解析结构化数据。LLM可以直接理解prompt body。方便更改和新增
  - FrontMatter中的字段：name、description、allowedTools、model、mode(inline or fork)、content（full/recent/none）
  - 分级：项目级（.minicoder/skills）,用户级（~/.minicoder/skills）
- inline/fork:
  - inline：默认的模式：skill的prompt注入到当前对话中。和之前的消息一样走Agent Loop
  - fork：隔离上下文进行执行，不影响也不受当前对话影响。执行完后只把结果摘要返回到主对话。适合/review
- ARGUMENTS：让Skill接受用户参数
Agent选择Skill流程
- 两阶段加载
  - 轻量注册：启动时只加载每个Skill的frontmatter（name、description），不加载完整的prompt body和专属工具。放在system prompt里，可以放到prompt cache的稳定前缀区，但每轮要多带一段token
  - 按需加载：判断匹配上的Skill时，调用LoadSkill工具，把Skill.md的完整prompt body激活到Agent的环境上下文。加载tool.json里申明的专属工具并注册到当前会话
- 目录Skill：支持意图识别和专属工具的Skill。多一个tool.json文件（注册工具）。具备一个好处（整套能力的打包移植：单元，sop，工具schema，工具实现代码，长文档参考，辅助脚本等）
- 完整流程：
  - 启动：扫描skill目录，加载所有的Skill的frontmatter轻量
  - 注入messages：告诉Agent有哪些Skill可用（name+description）
  - 注册命令：注册为Slash Command，支持/commit显式调用
  - 用户输入
  - 意图识别：Agent判断匹配 skill
  - Agent调用loadSkill
  - 完整SKILL.md+工具加载到user message动态上下文之前
  - 执行
三个内置的skill：资源嵌入机制编译进二进制，跟MewCode一起进行分发
- commit：分析diff生成规范提交
- review：在隔离上下文做客观审查
- test：负责测试并分析结果

12. Hook 系统 —— 生命周期钩子与自动化

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

13. SubAgent —— 子 Agent 与任务分发

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

14. Worktree —— Git 工作树并行开发

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

15. Agent Teams —— 从一次性子任务到长期协作团队

做什么：
怎么实现：
关键设计 / 取舍：
面试追问点：

16. 回顾与展望 —— 从一个空壳到一支团队

做什么：回顾 MewCode 从模型对话、工具调用到多 Agent 协作的完整演进路径，总结当前能力边界。
怎么实现：串联各子系统的数据流和控制流，形成端到端架构视图，并用真实任务复盘系统如何协同工作。
关键设计 / 取舍：功能复杂度、可靠性、成本和用户控制权之间如何平衡；哪些设计已稳定，哪些仍需实验验证。
面试追问点：项目中最难的问题是什么？做过哪些重构？目前最大的局限是什么？下一步会如何改进和评估？

MewCode 项目面试题库#

项目基础介绍#

Function Calling / 工具调用#

权限与安全#

MCP#

上下文压缩#

记忆系统#

Multi-Agent#

工程综合#

项目对比与补充#

AI 编程相关#

Claude Code 源码相关#

Harness 相关#

Agent 开发实习生八股题库#

01 Agent 入门#

02 关于主流 Agent 框架#

03 RAG#

04 MCP / Function Calling#

05 Agent 进阶以及实际应用#

06 Agent 实际场景题#

07 Skills#

08 开放性问题 & 前沿知识#

09 OpenClaw#

MewCode 项目学习#

目录#

1. 初识 Coding Agent#

2. 让 AI 开口说话#

3. 工具系统#

4. 让 Agent 自己干活#

5. System Prompt 设计#

6. 权限系统 —— 给 Agent 装上安全刹车#

7. MCP 协议 —— 开放式工具生态#

8. 上下文管理 —— 当 Token 开始烧钱#

9. 记忆系统 —— 跨会话的 Agent 记忆#

10. Slash Command —— 内置命令框架#

11. Skill 系统 —— 可复用的技能包#

12. Hook 系统 —— 生命周期钩子与自动化#

13. SubAgent —— 子 Agent 与任务分发#

14. Worktree —— Git 工作树并行开发#

15. Agent Teams —— 从一次性子任务到长期协作团队#

16. 回顾与展望 —— 从一个空壳到一支团队#