三种。
第一种是纯文本输出。
直接 print。好的地方是兼容性最强，任何终端都能正常显示。不好的地方也很明显，没有颜色、没有折叠、没有状态栏，信息密度低，用户体验差。
第二种是 Inline 流式输出，也是 PaiCLI 的默认方案。底部固定一个状态栏，显示当前模型、token 用量、上下文窗口占比、运行耗时。
最关键的是工具调用可以折叠。比如说 Agent 读了 3 个文件，终端只显示一行折叠摘要，按 Ctrl+O 展开可以查看具体内容。文件修改也有行内 diff 对比，改了什么一目了然。
第一弹，聚焦 Agent 核心架构——ReAct、Plan-and-Execute、Multi-Agent、异步并行。
这几个方向面试出现的频率最高，也是 PaiCLI 第 1、2、5、7 期的核心内容。
ReAct 是 Reasoning + Acting 的缩写，Yao et al.（姚顺雨）在 2022 年提出。
核心就一句话：让 LLM 在推理的同时能执行动作，根据动作结果继续推理，形成一个闭合的循环。
MCP 全称 Model Context Protocol，是 A 厂在 2024 年底推出的开放协议，一句话概括就是：给 AI 应用和外部工具之间定了一套标准通信接口。
老王这次换了副金丝眼镜，像极了某个互联网大厂的 CTO，眼神犀利但嘴角带笑，看起来今天心情不错。
老王翻了翻我的简历，“你这个 PaiCLI 写了三层记忆架构、RAG 向量检索、长上下文自适应，挺能吹的啊。”
（内心 OS：王哥你别说吹，这些我一行一行码出来的😤）
我说：“王哥，这几块确实是 PaiCLI 的核心。记忆系统做了三期，第 3 期做 Memory、第 4 期做 RAG 代码库理解、第 12 期做长上下文工程。最近还做了两个升级——长期记忆加了项目级隔离，代码检索从 RAG 一把梭改成了精确搜索优先、RAG 语义兜底。”
老王露出感兴趣的表情：“行，那就从记忆系统开始聊。”
老王这次没废话，直接开问：“PaiCLI 接了几家大模型？”
“目前支持 GLM、DeepSeek、Kimi、StepFun。”
“那你 API 调用的代码是不是写了四遍？”老王的语气里带着一点挑衅。
我笑了：“那不至于，一个基类搞定，每个 Provider 实现就二三十行。”
策略模式。定义一个统一接口，每个模型的 Provider 自己实现差异化逻辑。
接口需要声明两组能力。
第一组是行为能力，也就是对话方法。一般设计两个 chat 方法，一个带流式监听器参数，一个不带。不带监听器的方法内部调用带监听器的。
AI Agent 面试题系列第五弹，这次聊的是Prompt 与 Skill。
Prompt 是 Agent 的灵魂。
写得好，Agent 知道什么时候该用什么工具、碰到异常该怎么处理；写得差，Agent 干啥啥不行。
而 Skill 是把 prompt 工程化的手段——从“一坨几千字的 system prompt”变成“按场景按需加载的专家手册”，既能降低 token 的消耗，又能提升 Agent 的行为质量。
老王开门见山：“很多人觉得大模型能‘调用工具’很神奇，你给我讲讲 Function Calling 到底是怎么回事。”
Function Calling 是一个协议约定。
客户端在请求里声明有哪些工具可以用，包括工具名、功能描述、参数的 JSON Schema。LLM 在生成响应的时候，如果判断当前任务需要工具辅助，它会在响应里输出一段 JSON，告诉客户端“我想调用这个工具，参数是这些”。然后客户端拿到这段 JSON，自己去执行对应的逻辑，把执行结果包装成 tool message 塞回对话历史，再请求一次 LLM，LLM 看到结果继续推理。
3.3 万字 180 张手绘图，详解 41 道 Spring 面试高频题（让天下没有难背的八股），面渣背会这些 Spring 八股文，这次吊打面试官，我觉得稳了（手动 dog）。整理：沉默王二，戳转载链接，作者：三分恶，戳原文链接。
