Estars的博客

AI 应用开发实习简历

Fri, 12 Jun 2026 00:00:00 GMT

2027 届电子与信息工程硕士，聚焦大模型应用与 AI Agent 开发方向。

AI时代的一些思考与焦虑 - LINUX DO

Thu, 11 Jun 2026 00:00:00 GMT

AI时代的一些思考与焦虑 - LINUX DO#

来源: https://linux.do/t/topic/2281500/7 版块: 搞七捻三 | 标签: 纯水、快问快答、人工智能统计: 422 浏览量 · 91 赞 · 11 用户 · 15 条回复 爬取时间: 2026-06-01 12:39

📌 楼主原帖 — Wuuuuu（10小时前）#

AI现在如此发达，很多以前需要一整个团队甚至整个公司才能验证实现的idea，现在个人开发者都触手可及。并且御三家模型和国产模型，成本上差距还是很大的，有时候想用本地的Vibe Coding来验证实现一些自己的想法，却发现做出来的产品只是非常简陋的demo，完成度非常的低。所以本人对20刚出头这个年纪，应该把时间或者精力重心放在哪里非常迷茫，希望佬们可以指导一下。

赞: 12

💬 回复列表#

1. Histone / 默子（一元复始）· 10小时前#

怎么说呢，默子觉得虽然这些 idea 很好验证，但实际很多时候，难点并不在于把东西做出来，而是做出来之后的阶段可能更难。

对于 AI 的使用建议，我觉得现在就是要大量地使用，以此来投资自己，投资使用 AI 的方式。

虽然说”烧 token”是个很抽象的事情，但是随着 token 越烧越多，默子觉得还是会对不同的前沿模型更加了解：

熟悉它们的风格
搞清楚它们的底层原理

我觉得这些（方向）对于现在来说，无论是编程还是日后的发展，都要重要很多。

赞: 5

2. Wuuuuu（回复 Histone）· 10小时前#

哇，非常感谢默老师这么认真的回答。确实难点更多的是在完整的闭环和后续的迭代优化。然后对于要多烧token，非常非常非常认同。

我本身是嵌入式工程师，软硬件都有做，接触编程已经快五年时间了。从最开始只会在web网页和AI对话，然后cv带IDE里，到现在基本上都是自然语言编程。工作流的迭代也给我带来了很多思考和想法。我觉得更多的是当有很好的机会来临的时候，日常的这些思考和积累，在那时候可以拿得出手。

赞: 1

3. chancat（浴火重生）· 10小时前#

有这证在手，还会焦虑？

赞: 13

4. sakuraidc · 10小时前#

（无具体文字内容）

5. lessmanWith · 9小时前 ⭐深度回复#

鄙人不才，有过几段创业经历，也是深度vibe coding爱好者，佬友的问题我也思考过。以下跟您分享一下，提供一点思路：

从技术角度讲#

AI 让写代码变快了，但并没有让软件工程变简单。

一个产品从想法到真正变成可靠的软件，需要考虑的问题非常多：边界条件、错误处理、并发、资源释放、性能退化、日志、可观测性、兼容性、测试、回滚、部署、长期维护、后续扩展……这些东西 AI 可以写，能力越强的模型写得越好，但它很难代替工程师承担系统设计和工程判断。

您现在的思维，还是技术性思维，而技术永远是服务于产品，产品永远是服务于需求的。

系统化工程能力很重要#

AI 能够快速生成原型，但我们还需要判断：这个架构是不是能扩展？这个模块边界是不是清晰？这个数据结构以后会不会变成负担？这个异常场景有没有兜底，有没有设计冗余？这个功能上线之后出了问题了我怎么定位？

AI时代在技术方向上的积累，最值得花时间的是去培养”把一个东西做完整”的能力。您可以先要求自己做一个小产品，尝试在demo之外，做到：

能配置、能部署、能升级
有日志、有错误提示、有测试
数据不乱丢
接口有基本设计
文档能让别人看懂
出了问题自己知道怎么排查
下次想加功能，不需要推倒重来

技术本身并不是终点#

我学生时代曾经深深陷入一个误区：觉得只要技术足够强，产品自然会有人用。但现实往往不是这样。

产品唯一的目的，是满足人的需求。能满足越多人的需求，这个产品才越有价值，越有发展空间。

当 AI 让一个人也能做出以前团队才能做的东西时，真正拉开差距的，反而会变成：您能不能发现真实需求。

即使满足了需求，也还有落地问题#

一个产品能做出来，不代表它能活下来。真正落地会涉及到很多非技术问题：合规、隐私、数据安全、支付、客服、运营、推广、用户反馈、版本迭代、社区维护、成本控制。

比如推广，很多人往往发个链接、发篇博客就结束了，然后被动等待自己的产品突然得到曝光，这是不现实的。我们必须要知道目标用户在哪里，他们信任什么渠道。

给您的建议#

不要只把自己定位成写代码的人，而是尽早训练自己成为能完成闭环的人。这个闭环包括：

发现问题，判断需求
设计方案，快速验证
借助 AI 提高开发效率
用工程能力把东西做稳
上线给真实用户使用
收集反馈，持续迭代
考虑合规、运营、成本和增长

技术当然还要学，而且要认真学。但技术不要孤立地学，要有工程性思维做支撑，要尽可能找机会走过一个完整的产品闭环。

首先安心学好自己所在的细分领域的专业知识，同时大量使用AI，去尝试、去学习和完善自己使用AI的方式。如果可能，尝试借助AI去独立实现一个软件产品，多踩踩坑，完善一下自己的软件工程思维和能力。之后加入一个有实力的平台，这样您才能取得系统性的进步。

赞: 44 · 回复：完善到可以单开一篇的感觉、学到了、受益匪浅、完全可以开一篇帖子来介绍了、深刻阅读了感谢佬的分享、深刻收藏了、有共鸣有深度、受教了

6. Steve0328 · 8小时前#

个人的一些小看法#

我目前通过ai制作一些扩展/插件mod(web)，面向海外用户卖订阅。一个月除去ClaudeMax和codexPro的订阅费，净到手六百多刀。好在几乎不需要什么时间工作，每天1-2小时（想休息甚至可以不干）维护就好了。

我是0基础接触ai coding，完全的vibe编码。去年年底从cline开始，到反重力，再到目前的codex和Claude code。给我的感觉是ai越来越强大，学习的门槛也越来越低。

这让我逐渐形成了一个判断——在 AI 时代，“做出产品”的能力将不再像过去那样稀缺；真正稀缺的，是知道该做什么产品。

用户交互怎么设计、功能如何取舍、痛点在哪里——这些才是核心。创意，发现问题的能力，是最重要的。

AI是每个人的沃兹尼亚克，能把你脑子里的东西变成现实。但不是每个人都是乔布斯。

我的方法论其实很朴素：找人聊聊，看看他们在为什么烦恼，然后想怎么解决它。最后打开 Codex、Claude——验证成本几乎为零，最多花一点 token 费用就能初步判断一个方向有没有搞头。

有想法，打开Claude，喝杯咖啡跟它聊聊，做个MVP试试。多试几次你就能得到想要的。

赞: 13

7. za30312 / 清清清清 · 4小时前#

赞同上面几位大佬说的对于软件工程能力的提高。我也提一提我的看法：如果你觉得说的东西可能你都知道，但还是有些虚，可以找几个目标进行相关方面能力的提高——那就是考软考高级-系统架构师或者分析师。通过后我个人认为也是对你软件工程能力的证明。当然如果你有自己更明确的方向和目标就去执行就好。考这个，我是给一些迷茫或者焦虑的人一个建议，找一个好的目标。

赞: 1

8. Wuuuuu（回复 lessmanWith）· 3小时前#

非常感谢佬！确实刚从学校出来，很多时候还停留在”唯技术论”的思维当中。自身也确实有想过转型当产品经理，但碍于现有工作公司规模等属性及技术研发岗位的问题，比较难接触到一个完整的周期短的开发流程，所以对产品闭环能力的重视和锻炼不是太足够。

对于我来说，我觉得能够实操的改变是：虽然idea很多，但是不再想到啥就脑子一热开干，而是斟酌之后筛选出”好的机会”，然后把他耐心磨成产品。

但这又诱发出一个新的顾虑：前文提到楼主非计算机科班出身，对前后端技术知识的熟悉程度大概率是没有科班高的。若在产品打磨的过程中有同样定位的”竞品”比我提早出现，我往往会因此受挫。受挫的本质原因不是他比我做得快，而是从一开始觉得非常好的想法/需求，别人其实也是可以很快速的发现这个需求，最重要的是实现出来的速度比我快很多，那这就陷入了一个恶心循环。会增加下一次项目启动时候的成本，会顾虑会不会和之前一样，我这个想法实行到一半的时候，别人已经做完了，那就继续做下去就没什么意义了，因为没有先发优势了。

如果佬可以针对这个问题解答一下，那将万分感谢！！

赞: 1

9. Wuuuuu（回复 za30312）· 3小时前#

佬也在杭州吗哈哈，高软确实是今年的一个目标。

10. IsaacLiu · 3小时前#

我不是做嵌入式开发的，但是在 AI 的帮助下，做了相关的内容，几乎没有写一行代码。现阶段编程工作，语言和领域的门槛降低了，但是：

判断能力：问题的 root cause、solution 的抉择、AI 开发方向的指导
落地能力：有人买单（不一定是支付，是真要用）做出来的东西如何实际解决问题且不断优化

更重要了，跨越了途径而更看重问题本质了。

11. cbq / 黑山老妖 · 3小时前#

这是一个很好的话题，估计现在很多人都有这种焦虑的状态，望更多的佬留下多一些思考和建议，大家共同进步。

12. Night_Charm（文化宣导员）· 2小时前#

额，怎么说呢，软件开发的门槛被AI踹烂了，但是软件的商业化成本被拉高了。更多的是你的idea 可能实现难度会大幅下降。

举个例子，如果你想搭建一个工具，之前需要画原型、分析功能、分析实现所需要的技术，看这些技术是否会，如果不会需要自己学习。现在不需要了，在不考虑维护的情况下，你跟AI聊一下午就烧的出来这个工具的基础功能。

对应的商业化门槛被无限拉高，也就是会遇到一个谬论：如果AI开发这么简单，那谁还付费购买？自己vb不好么？

以及引出的另一个问题：AI跑出来的 MVP产品，并不是可商业化的产品。后续持续维护的成本会被拉高。毕竟整体使用AI跑出来的话，你对项目的掌控力约等于0，任何的修复都需要依托AI实现，这样的成本又被拉高了。

赞: 1

13. zhedream（种子用户）· 1小时前#

乍一看，以为要开发 IDEA 编辑器，多看下才反应过来。

焦虑是正常的，但不要焦虑，需要内卷。一句话：学习就完了，卷起来，要有专业深度。大家都能用 AI 干活，但一定是专业的人会更专业。

就像：大家都能拍高清的照，这不是有手就行？一个按钮的事情，有什么门槛么？但是为什么女朋友不喜欢。图片、视频都能AI了？但我连光影、布局、分镜基础都不懂，我凭什么比那些专业做的好。

就像学历贬值，是学历不重要了吗？no，恰恰相反，学历更重要了。学历贬值只是利好老板，技术贬值利好老板，AI提效也是利好老板。

AI让入门变得简单了，但入行可能已经是地狱级别的。同样薪资情况下，老板只会要高学历、会古法编程、懂源码、有更多工作经验的。

14. lessmanWith（回复 Wuuuuu）· 5分钟前 ⭐深度回复#

佬友客气了，这个顾虑非常真实，但这在软件市场其实是十分常见的现象。

我也特别能体会到您提到的”挫败感”，其实不妨换个角度想：一个想法在您做的过程中被别人做出来，这反而说明这个需求是真实存在的。但真正有价值的往往不是 idea 本身，而是对这个需求的理解深度、执行路径、用户触达方式，以及持续迭代能力。

明确自己的竞争点#

竞品的出现其实是市场反馈的一部分。在放弃之前，不妨思考：

这个竞品解决的是不是和我完全一样的问题？
它服务的客户群体与我的客户群体有多大的重合？
它的使用场景是不是和我的产品高度覆盖？
它有没有明显做得不顺手、不深入、不接地气的地方？
如果我是用户，我会在什么情况下换成我的产品？

“功能相似”不是判断竞品关系的强指标，“用户和场景是否相同”才是更值得纳入考量的项。

关于先发优势#

先发优势当然有价值，但很多时候我们会高估它。先发不等于赢家。很多早出来的产品只是先验证了方向，后面真正赢的，往往是更懂用户、更会迭代、更能稳定交付、更会触达市场的人。

先发优势通常只在几种情况下特别强：网络效应很明显、用户迁移成本很高、数据积累形成壁垒、渠道被提前占住、品牌心智已建立。

更现实的目标：先服务好一小撮具体的人#

比起去做一个”通用 AI 笔记工具”这样的大目标，先去做一个”给某类研究生整理论文阅读记录的 AI 笔记工具”。范围缩小以后，竞争压力自然会下降。

小成本验证#

别让一个 idea 一上来就变成一个三个月的大工程。先把它拆成一个一两周内能验证的最小版本。这样您就不会陷入那种”我做到一半，别人做完了，所以我完了”的恶性循环。

建立健康的项目判断方式#

不要把”没人做过”当成好机会的标准
不要把”别人比我快”当成自己失败的证明
不要把项目的意义完全建立在先发优势上
要学会小成本验证，而不是大成本豪赌
要有意识地积累自己的”根据地”

关于非科班出身#

科班与否决定的是技术起点，不是完整产品能力的起点。随着AI技术的发展，未来很多机会是那些能把需求、技术、交付、反馈串起来的人拿到。

心态建议#

20刚出头的时候，看到别人做得快、做得好，很容易焦虑。但长期来看，一个人真正的竞争力并不在于”这一次有没有抢在别人前面”，而是几年下来形成的稳定能力结构。

没必要追求去做第一个发现需求的人，而是努力成为更懂这个需求、更能交付解决方案、更能持续迭代的人。

💡 核心金句：不要把”没人做过”当成好机会的标准。没人做过，有可能是机会，也有可能是没人需要。有人做过，有可能是红海，也有可能是市场被验证了。

赞: 1

文档由小万自动整理爬取 · 来源: LINUX DO 社区 · 仅供个人参考

AI 烧 token 点网页的时代，要被这个 23k star 项目终结了

Thu, 11 Jun 2026 00:00:00 GMT

AI 烧 token 点网页的时代，要被这个 23k star 项目终结了#

来源： 微信公众号「AgentFlow」 作者： AgentFlow 发布时间： 2026年6月11日 10:04（新加坡） 原文链接： mp.weixin.qq.com

一个叫 OpenCLI 的开源项目，23.5k star，核心逻辑只有一句话：把任何网站固化成一条 CLI 命令，之后免费跑一万次。

它不是另一个 Playwright 封装，也不是又一个 MCP 工具。它是一种不同的思路。

AI 点网页，到底贵在哪#

AI agent 操作浏览器，大致经历了三代：

代际	方案	特点
第一代	Selenium/Playwright 脚本	确定性强，但每个网站都要手写，维护成本高
第二代	LLM 驱动（browser-use、Playwright MCP）	通用性好，但慢、贵、不稳定

成本对比（第三方测试数据）：

路线	Token 消耗	响应时间
Playwright MCP	≈ 11.4 万 token	10-60 秒
OpenCLI（CLI 路线）	≈ 2.7 万 token	数秒

更根本的问题是：LLM 驱动方案每次执行都要**「重新理解」**页面——就像雇了个实习生，每次都得现学现卖，没有 SOP。

OpenCLI 的核心逻辑：智能前置，执行免费#

作者 jackwener（Apache Arrow / DataFusion PMC 成员）把数据库的一个基本思想搬了进来：查询计划编译一次，执行多次。

对应到 Web 自动化就是：用 AI 探索一次目标网站，把操作逻辑固化成确定性的适配器，之后每次执行都是纯 JS 跑 DOM，零 LLM 参与。

「编译时智能 vs 运行时智能」

100 次任务：

LLM 驱动方案 → 调 100 次大模型
OpenCLI 路线 → 生成适配器时调 1 次，之后 99 次零成本执行

每个适配器本质是一个 TypeScript 模块，内含确定性的 CSS 选择器和页面交互逻辑：导航 → 提取 → 返回结构化 JSON。没有 LLM 随机性，跑一万次结果一致。

登录态问题，它怎么解#

这才是 OpenCLI 真正的差异点，也是国内开发者最该关注的地方。

小红书、知乎、B 站、微博——这些平台的 API 要么没有要么极贵，爬虫又风控严。browser-use 和 Stagehand 需要你手动注入凭证，Playwright 要自己管理 cookie。

OpenCLI 的答案：直接用你正在用的那个 Chrome。

架构#

1
CLI (Node.js) → 本地 daemon (localhost:19825, WebSocket) → Chrome 扩展 → 页面内执行 JS

扩展在你已登录会话的页面上下文里执行 JavaScript，凭证全程不离开浏览器，没有任何凭证存储。

「No competitor can say this.」—— 你的密码从来没离开过你的浏览器，因为它用的就是你的浏览器。

这对国内平台尤其致命：不用扫码、不用配 token、不触发风控，因为从平台的视角看，这就是你本人在用浏览器正常操作。

安装与使用#

Chrome 扩展： Chrome Web Store 搜索 OpenCLI
CLI 端： Node.js >= 20
Daemon： 首次执行 browser 命令时自动启动，常驻后台

现成适配器覆盖 100+ 站点（含大量中文平台）#

国内平台	国外平台
B站、知乎、小红书、微博、雪球、V2EX、BOSS直聘	Twitter/X、Reddit、HackerNews、YouTube

典型体验：opencli twitter search "关键词"，数秒返回结构化 JSON。

5 种认证策略（适配器自动选用）#

1
PUBLIC（无需登录）→ COOKIE → INTERCEPT（拦截API调用）→ UI（模拟操作）→ LOCAL（本地应用）

用户感知不到这些细节，装好就能跑。

Agent 集成#

v0.6.0 新增 opencli setup 交互式 TUI，一键把配置打进 Claude Code、Gemini CLI、Cursor、Codex 等工具。给 Claude Code 装上 opencli-browser skill，agent 就能直接用你登录中的 Chrome 搜推特、读 Reddit、发小红书，不需要任何 API key。

局限和边界#

适合	不适合
高频访问的固定站点	需要随机浏览的陌生页面
需要定时任务的数据抓取	动态变化的一次性任务
Agent 工作流里的确定性操作	—

通用浏览场景，官方建议配合 browser-use/Stagehand 一起用。

还有一个亮点：7 个桌面应用（Electron）适配器，通过 CDP（Chrome DevTools Protocol）驱动 Electron，Obsidian 也能变成 CLI 操作。

为什么这个范式值得关注#

“先用 agent 探索一次，再固化成命令”——这个叫 crystallize 的设计哲学，是 OpenCLI 最值得单独拿出来讲的东西。

这不只是一个产品功能，是 agent 工具的一种新范式。过去我们谈 AI agent，默认是「每次执行都让 AI 现场决策」。OpenCLI 在说：决策应该发生在设计时，不是运行时。

一旦流程跑通，就该把它变成零成本可重复的命令。

这个思路和当前社区趋势高度契合。2025 年底以来，「MCP 吃 token 太狠，agent 工具向 CLI/Skills 迁移」已经是明显趋势。OpenCLI 踩中了这个时间点，几个月从 15.6k 涨到 23.5k star，增速本身就说明了问题。

整理于 2026-06-11

Claude Code 深度操作指南：从零到专家，把这个 AI 编程助手真正用起来

Thu, 11 Jun 2026 00:00:00 GMT

Claude Code 深度操作指南：从零到专家，把这个 AI 编程助手真正用起来#

来源：架构工具栈
发布时间：2026年6月11日 09:23 广东
原文链接：https://mp.weixin.qq.com/s?__biz=Mzk0MzUyNTMwNA==&mid=2247498809&idx=1&sn=0636cd2d00942576c6417914adeb70c0

写在前面#

你可能已经知道 Claude Code 怎么用，但它比你想象的更强大。

这篇会把 Claude Code 的两种交互方式、IDE 集成、模型切换、上下文压缩、撤销恢复、图像理解、深度思考、命令历史管理、CLAUDE.md 记忆、SDK 与 MCP、Git Worktree 并行、GitHub Actions 自动化、以及常见故障排查全部串一遍——读完你应该能把它至少多用出 5 倍。

两种主要的交互方式#

Claude Code 提供两种主要的交互方式：

交互模式：运行 claude 启动 REPL 会话
单次模式：使用 claude -p "查询" 进行快速命令

可以参考：

Terminal window

1
# 启动交互模式
2
claude
3

4
# 以初始查询启动
5
claude "解释这个项目"
6

7
# 运行单个命令并退出
8
claude -p "这个函数做什么？"
9

10
# 处理管道内容
11
cat logs.txt | claude -p "分析这些错误"

对于 Claude Code Client 的常用参数和功能，可以访问官方文档：CLI 使用和控制 - Anthropic

IDE 集成：直接在编辑器里看到改动#

Claude Code 现在支持 VSCode 与 JetBrains：可以直接在 IDE 中看到 Claude Code 的改动，并在 IDE 中与其交互。

Linux / macOS 用户#

VSCode：在 VSCode 的内置终端唤起 Claude Code，插件将被自动安装
JetBrains：需要通过 JetBrains 应用市场下载 Claude Code [Beta] 插件

可能需要手动指定 IDE 或检查 IDE 连接，通过以下命令测试：

1
/ide

VSCode + WSL 用户#

请提前在 VSCode 插件商店安装 WSL 插件。

更多的用法，可以参考 Claude Code 的官方文档：IDE integrations - Anthropic

模型切换：Sonnet vs Opus#

Claude Code 支持 Claude Opus 4.8 与 Claude Sonnet 4.6 灵活切换：

模型	体验	计费倍率	推荐场景
Claude Sonnet 4.6	与 Opus 没有明显差别	1x（默认）	日常开发、绝大多数任务
Claude Opus 4.8	最强推理	5x	复杂调试、深度规划、长线任务

💡 强烈推荐使用 Claude Sonnet 4.6——使用体验与 Claude Opus 4.8 没有明显差别，但计费倍率仅为 Opus 的 1/5。

在 Claude Code 中使用此命令切换模型：

1
/model

上下文压缩：节省 token#

Claude Code 通常会有长上下文，建议使用以下斜杠命令来压缩以节省点数。较长的上下文往往需要更多点数。

1
/compact [您的描述]

恢复上一步修改#

Claude Code 支持使用 Ctrl+Z 或在 Vim 模式下使用 u 撤销 Claude Code 的上一步修改。

恢复以前的对话#

使用以下命令可以恢复上次的对话：

Terminal window

1
claude --continue

这会立即恢复最近的对话，无需任何提示。

如果需要在多个历史对话中选择，可以输入此命令：

Terminal window

1
claude --resume

这会显示一个交互式对话选择器，显示：

对话开始时间
初始提示或对话摘要
消息数量

使用箭头键导航并按 Enter 选择对话，可以用这个方法选择上下文。

图像信息处理#

Claude Code 可以处理图像信息，可以使用以下任何方法：

将图像拖放到 Claude Code 窗口中（在 macOS 上）
复制图像并使用 Ctrl+v 粘贴到 CLI 中（在 macOS 上）
提供图像路径：分析这个图像：/path/to/your/image.png

可以完全使用自然语言要求它进行工作，如：

“这是错误的截图。是什么导致了它？”
“这个图像显示了什么？”
“描述这个截图中的 UI 元素。”
“生成 CSS 以匹配这个设计模型。”
“什么 HTML 结构可以重新创建这个组件？“

深入思考（Deep Thinking）#

需要通过自然语言要求它进行深入思考：

“我需要使用 OAuth2 为我们的 API 实现一个新的身份验证系统。深入思考在我们的代码库中实现这一点的最佳方法。”
“思考这种方法中潜在的安全漏洞。”
“更深入地思考我们应该处理的边缘情况。”

⚠️ 推荐在使用复杂问题的时候使用这一功能，这也会消耗大量的额度点数。

命令历史管理#

历史按工作目录存储
使用 /clear 命令清除
使用上 / 下箭头导航
Ctrl+R：反向搜索历史（如果终端支持）
注意：历史扩展（!）默认禁用

CLAUDE.md：存储项目记忆#

可以使用以下命令设置一个 CLAUDE.md 文件来存储重要的项目信息、约定和常用命令：

1
/init

CLAUDE.md 里建议放这些内容：

常用命令（构建、测试、lint）以避免重复搜索
代码风格偏好和命名约定
特定于项目的重要架构模式

CLAUDE.md 记忆可用于与团队共享的指令和个人偏好。

更多关于记忆的设置，可以访问此官方文档了解：Claude Code 概述 - Anthropic。常用用法参考：管理 Claude 的记忆 - Anthropic。

SDK 与 MCP#

Claude Code Python SDK#

Claude Code 支持 Python SDK，请参考官方文档：Claude Code SDK - Anthropic。

直接访问 Python SDK GitHub 仓库：GitHub - anthropics/claude-code-sdk-python。

MCP 模型上下文协议#

模型上下文协议（MCP）是一个开放协议，使 LLM 能够访问外部工具和数据源。

这是高级功能，可以访问此文档获取更多配置信息：Introduction - Model Context Protocol。

Claude Code 不仅支持接入 MCP，同样支持作为 MCP 服务器等各类高级功能，可以访问此文档获得更多信息：教程 - Anthropic。

Git 中的高级用法#

自然语言操作 Git#

Claude Code 支持使用自然语言操作 Git，如：

“提交我的更改”
“创建一个 PR”
“哪个提交在去年十二月添加了 markdown 测试？”
“在 main 分支上变基并解决任何合并冲突”

Git Worktree：并行隔离的编码环境#

如果需要同时处理多个任务，并在 Claude Code 实例之间完全隔离代码，可以使用 Git Worktree 功能。

Git 工作树允许从同一存储库中检出多个分支到单独的目录。每个工作树都有自己的工作目录，文件是隔离的，同时共享相同的 Git 历史。

创建新工作树：

Terminal window

1
# 创建带有新分支的工作树
2
git worktree add ../project-feature-a -b feature-a
3

4
# 或使用现有分支创建工作树
5
git worktree add ../project-bugfix bugfix-123

这会创建一个包含存储库单独工作副本的新目录。

在每个工作树中运行 Claude Code：

Terminal window

1
# 导航到您的工作树
2
cd ../project-feature-a
3

4
# 在这个隔离环境中运行 Claude Code
5
claude

在另一个终端中：

Terminal window

1
cd ../project-bugfix
2
claude

管理工作树：

Terminal window

1
# 列出所有工作树
2
git worktree list
3

4
# 完成后移除工作树
5
git worktree remove ../project-feature-a

Worktree + Claude Code 的优势

每个工作树都有自己独立的文件状态，非常适合并行 Claude Code 会话
在一个工作树中所做的更改不会影响其他工作树，防止 Claude 实例相互干扰
所有工作树共享相同的 Git 历史和远程连接
对于长时间运行的任务，可以让 Claude 在一个工作树中工作，同时你在另一个工作树中继续开发
使用描述性目录名称，以便轻松识别每个工作树的任务

Worktree 环境初始化

记得根据项目的设置在每个新工作树中初始化开发环境。根据技术栈，这可能包括：

JavaScript 项目：运行依赖安装（npm install、yarn）
Python 项目：设置虚拟环境或使用包管理器安装
其他语言：遵循项目的标准设置流程

GitHub Actions：@claude 触发自动化#

此功能仍是 Beta 版本，可访问此链接获取使用：

这是一个适用于 GitHub PR 和 issues 的通用 Claude Code 动作，可以回答问题并实现代码更改。此动作会在评论中监听触发词并根据请求激活 Claude 动作。

Claude Code GitHub Actions 为 GitHub 工作流程带来 AI 驱动的自动化。只需在任何 PR 或 issue 中简单地提及 @claude，Claude 就可以分析代码、创建拉取请求、实现功能和修复错误——所有这些都遵循项目的标准。
——Anthropic

通过以下命令部署 Claude Code GitHub App，此命令将引导你完成设置 GitHub 应用和所需的密钥：

1
/install-github-app

安装成功后，可用 @ 命令，如：

@claude 根据 issue 描述实现此功能
@claude 我应该如何为此端点实现用户身份验证？

其他自然语言功能#

识别未文档化的代码

“在 auth 模块中查找没有适当 JSDoc 注释的函数”

生成文档

“为 auth.js 中未文档化的函数添加 JSDoc 注释”

理解陌生代码

“支付处理系统做什么？"
"查找用户权限在哪里被检查"
"解释缓存层是如何工作的”

智能编辑代码

“为注册表单添加输入验证"
"重构日志记录器以使用新的 API"
"修复工作队列中的竞态条件”

测试或编辑代码

“运行 auth 模块的测试并修复失败"
"查找并修复安全漏洞"
"解释为什么这个测试失败了”

常用斜杠命令、CLI 命令、参数与快捷键#

参考：交互模式 - Anthropic

其他高级功能#

类 Unix 工具：Claude Code 可以被用作类 Unix 工具——教程 - Anthropic
自定义斜杠指令：教程 - Anthropic
$ARGUMENTS 添加命令参数：教程 - Anthropic
高级设置：可以参考此文档——Claude Code 设置 - Anthropic
安全设置：请参考此官方文档——管理权限和安全 - Anthropic

常见问题排查#

Q：Claude Code 如何存储记忆？
A：Claude Code 将记忆存储在 ~/.claude 中，如果没有特殊要求，请不要删除此目录。

Q：Claude Code 偶尔回复错误的模型名称，这是为什么？
A：这是因为 Claude Code 在使用简单任务时，不会使用 Claude 4 系列模型。可以了解：Bedrock、Vertex 和代理 - Anthropic。

Q：Claude Code 执行的命令行参数错误？
A：此类问题在 WSL 上常见，是 Agent 自身的错误。推荐使用 macOS / Ubuntu，这类环境往往问题较少。

Q：Claude Code 如何彻底清理？
A：可以执行以下命令清理 Claude Code 的登录信息：

Terminal window

1
rm ~/.claude* -rf

Q：Claude Code 出现 API Error / Tools Error？
A：这通常是网络问题，请退出后使用 claude -c 重新执行。如果问题依然存在，请联系售后支持。

Q：Claude Code 在登录使用 OAuth 时验证错误？
A：请确保环境变量中没有配置任何代理再进行登录验证。
如果问题仍然存在，请无视弹出的浏览器并复制终端中的链接并打开，通过验证码方式验证。

Q：Claude Code 长时间没有响应？
A：建议按下 Ctrl+C 并重启 Claude Code，这往往是网络问题。
如果命令行仍然无响应，建议杀死进程并重新进行会话，这将不会影响工作进度。
可以通过以下命令恢复上次的会话：

Terminal window

1
claude -c

若问题仍然出现，请寻求售后支持。

写在最后#

把上面这些功能串起来看，Claude Code 真正的能力远不止”在终端里写代码”——Worktree 并行 + 多 IDE 集成 + @claude GitHub Actions + 自定义 Skills + MCP，组合起来基本就是把一个 AI 工程师塞进了你的开发流程里。

对国内开发者来说，最大的卡点反而不是怎么用，而是怎么稳定连上 Claude Opus 4.8 这种旗舰模型——官方订阅需要海外信用卡、海外网络、还有时不时被封号的风险。如果想直接跳过这些麻烦，可以看看 Code80，真实订阅账号转 API，换个 endpoint 就能在 Claude Code 里直接跑 Opus 4.8、Sonnet 4.6，体验跟官方完全一致。详情可以到官网了解：code.ai80.vip。

常见问题（FAQ）#

Q1：交互模式和单次模式怎么选？#

A：长任务、要反复迭代用交互模式（claude 启动 REPL）；一次性问答、脚本调用、管道处理用单次模式（claude -p "..."）。比如 cat logs.txt | claude -p "分析这些错误" 这种就是单次模式的典型用法。

Q2：模型默认是 Sonnet，要不要切到 Opus？#

A：绝大多数情况下不用切——Sonnet 4.6 体验和 Opus 4.8 没有明显差别，但点数只用 1/5。只在复杂调试、深度规划、安全审查、长线研究这类真正吃推理的任务上切到 Opus。/model 命令随时可以换。

Q3：上下文太长导致点数烧得快怎么办？#

A：用 /compact [描述] 压缩上下文。这个命令会让 Claude 把当前会话的关键信息总结成精简版，然后基于压缩后的上下文继续，能显著降低 token 消耗。长会话建议每跑一段就 compact 一次。

Q4：Git Worktree + Claude Code 到底有什么用？#

A：可以同时跑多个 Claude Code 实例处理不同任务，彼此互不干扰。比如一个工作树里让 Claude 跑长时间重构，另一个工作树里你自己继续开发新功能。每个工作树文件状态独立，共享同一份 Git 历史。适合”一边让 AI 干活、一边自己也在写”的并行场景。

Q5：CLAUDE.md 和 /init 是什么关系？#

A：/init 是一键生成 CLAUDE.md 的命令——它会扫描你的项目，自动生成一份初始的 CLAUDE.md。生成之后你可以再手动补充：常用命令（build/test/lint）、代码风格、架构模式。CLAUDE.md 每次会话开始时 Claude 都会自动读，相当于给它的”项目入门文档”。

Q6：怎么用 @claude 在 GitHub PR 里触发 Claude Code？#

A：先在仓库里跑 /install-github-app 配置 GitHub App 和密钥。装好之后，在任何 PR 或 Issue 评论里 @claude 帮我实现这个功能 就能触发。它会分析代码、创建 PR、实现功能或修复 bug，按项目规范走。这是个 Beta 功能。

Q7：Claude Code 总是 API Error 或长时间无响应？#

A：大概率是网络问题。先 Ctrl+C 中断，用 claude -c 恢复上次会话。如果还不行就杀进程重启——不会丢工作进度，下次还能 claude -c 续上。OAuth 登录失败的话，确保环境变量里没配代理，或者直接复制终端里的链接手动打开做验证。

Q8：国内开发者怎么稳定用上 Claude Opus 4.8？#

A：官方 Claude 订阅需要海外信用卡 + 海外稳定网络环境，且有封号风险。可以走 Code80 这种真实订阅账号转 API 的渠道——按拿到的 Base URL 和 Key 配进 Claude Code 或 CC Switch 就能直接跑 Opus 4.8，体验跟官方一致。

本文整理自「架构工具栈」微信公众号

Pi Agent 的自举哲学：一个会自己写代码给自己用的 Agent

Thu, 11 Jun 2026 00:00:00 GMT

Pi Agent 的自举哲学：一个会自己写代码给自己用的 Agent#

来源： 微信公众号「努力的Jerry Plus」 作者： 努力的Jerry Plus 发布时间： 2026年6月5日 19:55（上海） 原文链接： https://mp.weixin.qq.com/s/euhLBJAW7_dAHM5Jvr1mbw

引言#

2026 年的 Agent 框架市场，用一个字形容就是：卷。

LangChain 团队在给 LangGraph 加 graph state machine
CrewAI 在推 multi-agent orchestration
微软在往 AutoGen 里塞 research agent 和 code executor
Anthropic 都在给 Claude Code 加 MCP 协议生态

每个团队都在做同一件事——往自己的框架里塞更多功能。

接着 Armin Ronacher 发布了一个只有 4 个工具的 Agent 框架。

这就像所有餐厅都在比谁的菜单更长，突然有人开了一家只卖四道菜的店——而且排队的人还不少。

候选选手对比#

选了 4 个有代表性的对手，加上 Pi：

框架	背后	核心范式	一句话定位
LangGraph	LangChain Inc（风投支撑）	结构化/图状态机	企业级工作流编排引擎
CrewAI	Joaquin Campero（独立开发者）	角色扮演/多 Agent	给 Agent 分角色协作
AutoGen	微软研究院	多 Agent 对话/辩论	让多个 Agent 互相讨论
Pi	Armin Ronacher + 社区	极简/自举	4 个工具，Agent 自己扩展

没有选 Claude Code / Codex CLI，因为它们是产品而不是框架——虽然在实际使用中它们确实是 Pi 最直接的竞品。

全维度对比#

维度	LangGraph	CrewAI	AutoGen	Pi
核心哲学	图状态机	角色扮演	多Agent对话	YAGNI+自举
工具数量	20-50+	10-30	内置协议	4
核心代码量	数万行	数千行	数万行	~418行
扩展方式	写Node/Edge	定义Role	定义Agent类	Agent自写
Prompt 长度	很长	中等	长	极短
调试体验	LangSmith	任务日志	对话历史	树Session
上手门槛	中	低	中	高
适合场景	企业工作流	多角色任务	研究实验	定制编程
GitHub Stars	~80K	~35K	~45K	(含OpenClaw)

深度分析#

工具数量的悖论#

这是最直观的差异，也是最容易被误解的。

LangGraph 的工具列表可以轻松超过 50 个——文件操作、数据库、搜索引擎、API 客户端、向量存储、记忆管理、JSON Schema 验证……每个都经过精心设计，有完整的类型标注和错误处理。

CrewAI 少一些，但也在 10-30 个之间，按角色分类。

AutoGen 不太强调”工具”概念，但它内置的 Agent 类型协议和通信机制本质上也是一种预置能力。

Pi：4 个。

数字上的差距看起来大得荒谬。但这里有一个反直觉的事实：工具越多，Agent 的决策空间越大，出错概率越高。

想象一下，你让一个 Agent”帮我修这个 bug”。如果它面前有 50 个工具，它需要先判断该用哪一个。这个判断本身就会消耗 token、消耗时间、而且可能判断错。而如果只有 4 个工具，它的选择范围极小——读代码、改代码、跑测试。几乎不会选错工具。

这不是说少一定好。而是说：工具数量和能力边界是两回事。

Pi 用 4 个工具通过自举可以达到的能力边界，理论上和其他框架用 50 个工具达到的边界是一样的。区别在于到达的方式不同——一个是预先铺好的高速公路，一个是自己踩出来的小路。前者快但僵化，后者慢但灵活。

扩展方式的分水岭#

这是所有维度中最重要的一个。因为它决定了框架演化的方向。

传统框架的扩展 = 开发者写代码。

你想给 LangGraph 加一个新能力？写一个自定义 Node，注册到图里
想给 CrewAI 加新角色？定义一个新的 Agent 类，写好 role 和 goal，挂进 crew
想给 AutoGen 加新的对话协议？继承 BaseChatAgent，实现你的消息处理逻辑

这些都需要人类开发者动手。每加一个能力，都是人在写代码。

Pi 的扩展 = Agent 写代码。 Agent 发现自己缺能力 → 自己写脚本补上 → 后续复用。全程不需要人参与。

这两种模式的差异，不只是”谁写代码”这么简单。它意味着：

传统框架的能力上限 = 开发团队的交付速度
Pi 的能力上限 = LLM 的编码能力 × 迭代次数

前者受限于人力。后者随着模型能力的提升自动增长。GPT-5 比 GPT-4 更会写代码？那 Pi 的自举能力就自动变强了。不需要等框架作者发新版。

这可能是未来三五年 Agent 框架领域最重要的分岔路。

System Prompt 的隐藏成本#

这个点很少有人提，但被严重低估了。

System Prompt 的长度直接影响两件事：token 消耗和注意力稀释。

每次 Agent 开始一个任务，完整的 system prompt 都会被送入 LLM。如果你的 system prompt 有 5000 字符（这在功能丰富的框架里很常见），那每一个任务的每一次思考循环都要消耗这些 token。一天跑 100 个任务呢？一年呢？

更隐蔽的问题是注意力稀释。LLM 的上下文窗口是有限的。当 system prompt 里塞满了 20 个工具的详细描述、参数说明、使用示例时，LLM 分配给”理解用户真实意图”的注意力资源就会减少。

Pi 的 system prompt 是所有编程 Agent 中最短的之一。 原因无他——工具只有 4 个，没什么好描述的。省下来的 token 和注意力，全部集中在任务本身。

调试体验：被严重低估的竞争力#

用过 Agent 框架的人都知道一个痛苦的事实：当 Agent 出问题时，你很难搞清楚它为什么这么做。

LangGraph 有 LangSmith 可视化平台，能看到图的执行路径——这是目前最好的调试体验之一
CrewAI 有任务日志，能看到每个角色做了什么
AutoGen 能看到多轮对话记录

但这些本质上都是扁平的日志。你看到的是”Agent A 说了 X，Agent B 回了 Y”。你看不到的是：“在那一刻，Agent A 为什么选择说 X 而不是 Z？”

Pi 的树形 Session 直接回答了这个问题。 每个决策分支都被保留，你可以完整回溯推理链路。配合热重载，你甚至可以在观察到问题后立即修改 Agent 的行为，接着在下一个任务里验证修复效果。

这种”观察→诊断→修改→验证”的闭环速度，是目前其他框架难以企及的。

谁该用什么？#

你的情况	推荐框架
企业级复杂工作流	LangGraph（最成熟的编排方案）
多角色协作场景	CrewAI（最低上手门槛）
学术研究/多 Agent 实验	AutoGen（微软背书 + 灵活协议）
深度定制编程 Agent	Pi（自举 + 树形Session + 热重载）
不想碰框架，只想用产品	Claude Code / Codex（开箱即用的编程 Agent）

没有万能解。Pi 不是要取代谁。它是在回答一个不同的问题。

说句实话#

写这个对比的时候，作者一直在提醒自己不要变成 Pi 的推销员。

事实是：Pi 在很多客观指标上都处于劣势。工具少、社区小、文档薄、上手门槛高、不适合非技术用户。如果你需要一个开箱即用的方案去解决具体业务问题，Pi 大概率不是最优选。

但 Pi 的价值从来不在于”更好用”，而在于提出了一个更好的问题。

当所有人都在问”我的框架还能加什么功能”的时候，Pi 问的是”我的框架能不能不加功能也能变强”。

这两个问题的答案，指向了两条完全不同的路。目前我们还不知道哪条路通向终点。但我们知道的是：如果所有人都走同一条路，那这条路大概率不是最好的那条。

有人愿意走另一条路。这件事本身就值得写一篇文章。

📌 Pi Agent 系列#

🔗 第 1 篇：「当所有 Agent 框架都在堆功能时，有人只写了 4 个工具」
🔗 第 2 篇：「一个会自己写代码给自己用的 Agent：Pi 的自举哲学」（本文）
🔗 后续文章陆续更新中

整理于 2026-06-11 | 原文链接：https://mp.weixin.qq.com/s/euhLBJAW7_dAHM5Jvr1mbw

一个面试备考 Skill，根据你的简历和全网真实面经自动生成个性化题目，每题带源链接

Thu, 11 Jun 2026 00:00:00 GMT

一个面试备考 Skill，根据你的简历和全网真实面经自动生成个性化题目，每题带源链接#

来源： 微信公众号「几乎满级」 作者： 几乎满级 发布时间： 2026年6月10日 17:00（江苏） 原文链接： mp.weixin.qq.com

InterviewRadar（面试雷达）#

根据你的简历和全网真实面经，自动生成一份个性化的面试备考包。一个可给 Claude Code 或 Codex 使用的面试准备工作流（Agent Skill）。

解决的问题#

市面上静态的八股文题库命中率低（可能不到 10%），面试官真正问的往往是根据你简历动态发散的题目；而牛客、小红书上的真实面经虽然多，但靠自己一篇篇筛，既耗时又很难筛出跟简历相关的那些。

InterviewRadar 的做法#

同时解决这两个问题——它抓取全网真实面经，再结合你的个人简历，生成一份锚定你具体项目的个性化中文面试备考包。每一道题都带有原始抓取链接，拒绝 AI 凭空捏造。

工作流程（六步）#

整个流程分六步，由大模型和 Python 脚本各司其职：

角色	负责内容
大模型	推理——处理领域知识、生成搜索种子词、把题目跟你的简历项目做逻辑锚定
Python 脚本	”确定性脏活”——HTML 解析、时效过滤、去重排序，以及抓取失败时的降级处理

具体步骤#

输入：你先给它一份简历和一句模糊的岗位方向，比如”AI 应用开发”。简历格式不限，文字 PDF、图片、扫描件都行。
全网搜索：通过 WebSearch 在全网发现牛客网、公开博客上的真实面经 URL，按域名分配对应的抓取连接器。
时效过滤：抓回来的内容默认用 730 天（近两年）的时效硬过滤，再按”频次×时效”的权重排序，淘汰掉过时的考点。
项目挂靠：把筛选出来的高频真题一道一道挂靠到你简历里的具体项目上，生成连环追问链。
输出：一份 Markdown 中文备考包，每道题都带源链接。

数据源支持#

平台	支持方式
牛客网	默认支持，零配置
GitHub 面经仓库	Markdown 题库，零配置
知乎、CSDN 等博客	正文抓取，零配置
小红书	需配合 MediaCrawler（反爬严格）

MediaCrawler 模式#

模式	说明
fast 模式	只抓标题、正文文本、标签和时间
deep 模式	下载图片 + OCR 提取图片中的面经文本（小红书上很多面经是截图）

项目信息#

开发者： KunChen1110
开源协议： MIT
Stars： 136
项目地址： https://github.com/KunChen1110/InterviewRadar

整理于 2026-06-11

企业落地 Agent 案例讲解——数据分析领域

Thu, 11 Jun 2026 00:00:00 GMT

企业落地 Agent 案例讲解——数据分析领域#

来源：LINUX DO | 作者：gxt | 2026-06-11 原文：linux.do/t/topic/2366310

最近一直开会做其他项目，非常忙，现在抽吃饭时间敲一下。老实说纠结了很久，要不要写这篇文章，害怕大家听不明白，思考了两天，终于知道该怎么给大家讲这个项目。

本来想叫”问数机器人”，想了一下不合适，于是让 AI 想了一下名字，于是就出来了——智能数据管家 Agent。

事先说明，这个 Agent 真的非常难，涉及非常多的细节，对技术也有一定的要求，并且目前来看不能商用，找我咨询的那家公司也只是内部数据岗人员小部分使用。我只能尽我所能的用大白话告诉大家一些参考的方向，各家公司有各家公司的情况，主要是分享一下思路。

业务视角#

假设现在要做一个问数机器人——用自然语言查询数据的机器人。比如你跟 AI 说”查一下昨天的退款后 GMV 是多少”、“查一下某天的库存”，AI 就会快速给你答案。

但事实上这用 BI 数据看板拖拽也能实现，只是提高了一点效率。业务本身更想要的是：某个指标发生了异常，是什么时候发生的？导致这一情况出现的原因是什么？AI 有没有什么建议能给到我？

比如说：昨天退款后 GMV 突然下滑了一百万，AI 会自动推送给我——“昨天某个产品由于价格上涨的问题，导致 GMV 下滑，AI 建议调整定价策略”。

Agent 实现的三大功能#

1. 数据驾驶舱#

将公司核心的指标都呈现，一眼就能知道当前公司的经营状况。比如：

当前库存
当前卖了多少
目标完成度是多少

2. 问数机器人#

自然语言输入后，AI 输出数据或者 Excel 表格。

3. 数据预警#

当某个指标发生重大变化时，直接查找原因，并推送到个人或群聊，并给出相关建议。

实现思路#

前提：完善的指标体系#

并不一定要求是全公司的，哪怕是某一个部门、某个小子公司或某个中心都可以。这套方向指向性非常强，一定要结合业务场景去做。

指标体系背后必须有数仓和主数据系统支撑。

第一步：梳理核心指标#

把库存货值、目标完成度、老板关心的指标都丢进去，可以的话加上时间筛选器。

第二步：解决两大难关#

难关一：数据安全#

如果要把数据库直接丢给 AI，是否安全？做法是：采购企业版（Codex / qoder / trae 等），签订安全协议，保证数据不外泄。大部分公司都是这样处理的。

难关二：AI 幻觉（瞎编数据）#

解决方法：

大宽表 + 维度表 + 指标清单：在数仓里针对销售做一个销售大宽表，再做一个库存大宽表。把维度表和指标清单一起给 AI，做好配置。
不让 AI 直接写 SQL：让 AI 以传参的形式——业务人员问什么指标，AI 就传入什么指标，然后去执行取数操作。从数据源阶段就控制死，AI 只能执行聚合汇总操作。
输出必须带来源：AI 每次回答要求输出数据时必须带上——查询了哪个表、哪个字段、什么时间段、过滤条件是什么。这样给数据岗使用，即使有问题他们也看得出来，前期也会大量测试校验。

自然语言 → 数据语言的转化#

做一个语义库，把自然语言翻译为数据语言。整体流程：

1
AI 接收指令
2
  → 结合语义库翻译为专业数据提示词
3
  → 提取确认需要的维度和指标
4
  → 传参执行 SQL
5
  → AI 汇总分析并输出数据与结论

第三步：数据预警与指标拆解#

这一步需要业务部门自行去拆解指标。作者协调了业务部负责人一起干的。

指标拆解示例（运营思路）：

1
退款后 GMV = 流量（访客数）× 转化率（人群）× 客单价 × 退款率

假设退款后 GMV 下滑严重 → 逐一排查各因子
流量、转化率都没问题 → 检查客单价是否过高，是否被竞品狙击
客单价、访客数也没问题 → 看投流手投的流量是否符合公司人群
前面都没问题 → 看退款率是否过高，产品本身出了问题

核心原则： 最终 AI 输出的结论一定是有迹可循的，结合公司场景定制化输出，不让 AI 自己瞎编。

价值与展望#

这个 Agent 目前在公司内稳定运行了一段时间，改变了过去的工作方式：

过去： 人被动找数据、找问题
现在： 数据找人、问题找人

从传统的工作方式变为交互式的——AI 给结论，人来不断调试。持续运行下去，对整个业务部门来说价值非常大。

作者的判断：市面上每一家规模起来的公司，一定会做这个。

传统数据分析、数据开发的工作岗位，一定会在 AI 的冲击下做出改变。过去数据分析里常说做归因分析，AI 出现后就变成了——AI 告诉你原因，你要去想办法去沟通、去协调、去解决。无法适应这个工作方式的同学，可能还会被替代优化。

数据： 201 浏览量，20 赞，7 用户回复

大型项目使用大模型开发的工作流和方案讨论

Thu, 11 Jun 2026 00:00:00 GMT

大型项目使用大模型开发的工作流和方案讨论#

来源：LINUX DO - 开发调优作者：bigleo 浏览量：278 | 赞：19 | 回复：22页 | 参与用户：10人

📝 主楼原文#

bigleo 提出：

面对大型项目且模块多而复杂的情况，有没有好的 AI 开发方案？如果只给出需求让大模型自己做计划，它可能压根不会参考项目中已有的模块代码，或者开发及查 bug、Code Review 时大模型需要每次现去读取代码，可能存在读取的代码不准确，或读取代码导致上下文越来越大，后续开发更混乱。

📋 楼主梳理的问题清单#

1. 缺乏项目全局认知#

如果只是把需求直接丢给大模型，让它自己拆解和制定开发计划，它往往只能基于需求本身进行推理，很难主动理解项目现有架构、模块边界、设计规范以及历史实现方式。结果就是容易重复造轮子，甚至给出与现有架构冲突的方案。

2. 无法充分复用已有代码#

项目里明明已经有类似功能或公共模块，但大模型未必能发现。开发出来的新代码可能绕开现有能力，导致逻辑重复、维护成本增加。

3. 上下文窗口限制#

开发、排查 Bug、Code Review 时，大模型往往需要临时读取相关代码。随着代码、日志、需求文档不断加入上下文，Token 消耗越来越大，后续可能出现上下文污染、遗忘早期信息、分析结果前后不一致等问题。

4. 代码理解准确性问题#

即使使用代码检索（RAG）方案，大模型读取到的代码片段也可能不完整。缺少调用链、依赖关系、运行时信息时，容易做出错误判断。有时候分析 Bug 的结论看起来很合理，但实际上是建立在错误代码理解之上的。

5. 开发过程缺乏持续记忆#

今天分析了某个模块，明天继续开发时可能又要重新让模型学习一遍。对项目约定、业务规则、架构原则缺少长期记忆和沉淀，导致每次会话都在重复做项目认知工作。

6. Code Review 效果不稳定#

AI 能发现一些明显问题，但对于复杂业务逻辑、架构设计缺陷、历史兼容性问题，效果参差不齐，很依赖它是否恰好获取到了足够的上下文。

💬 精彩回复整理#

🏆 acrx10Zz（粪池蝶泳总冠军）— 高赞回复#

这种开发方式的交互入口是跟 AI 协同讨论的 RFC 文档 和 Plans 执行计划。

RFC：和 AI 交互意见过程中产生的意见稿和决策意向

ADR：一些敲定的决策规则会沉淀为架构决策记录

Plans：具体的实施计划，包含这个迭代需要执行的技术细节和验收清单

这些就是和 AI 沟通中需要反复校对的内容。一旦计划敲定，开 Goal 执行，AI 需要向我提供 Report 报告和相关证据链。
总结： 输入 = 执行计划 Plans，输出 = AI 提供的包含验收清单和证据链的 Report。只对输入和输出的产物负责，中间执行过程由 AI 全权处理。

🏆 noshenxian（神仙）#

如果是在老的框架上改，让它参考，总是多做一些无用的东西出来。但新项目全 AI 开发的，我个人感受来说只能 AI 去改了，人已经改不动了。其实维护是个问题。
做法类似，效果有一些，但还是会不可控，很容易出现偏差。我的原因还是因为懒，后来我就开始死磕详细设计了。

🏆 cheviChan（不二之选）— 逐条心得#

分享下自己的心得，与各位佬一起学习进步：

缺乏项目全局认知 & 无法充分复用已有代码 — 现在的 Agent 已经能很好解决这两个问题了，提示词限制好就行了，或在 claude.md、rules、agent.md 定好规范。注意不要用太差的模型，在 Cursor、Claude Code、Codex 这些 Agent 上，国内御三家也能基本完成任务。
上下文窗口限制 — 还是得先拆分好需求。
代码理解准确性问题 — 和 Agent 与模型有关，试过同样的问题被 Minimax 忽悠过，重要分析还是 GPT 比较稳。
开发过程缺乏持续记忆 — 也在探索中。目前做法：如果某个工作做得很吃力但最终兜兜转完成了，就让它记下来，它会自己总结到项目文件中去。
Code Review 效果不稳定 — 设计大方向和重要节点还是人工 Review，其他就跑单测和后面交给测试人员了。

到实际开发过程中，感觉都不用省 Token 了，能完成任务就好。

🏆 coldwater#

推荐使用：

github.com/mindfold-ai/Trellis

github.com/coldwateryi/trellis-skills

已经在中小型项目验证过，效果可接受。

🏆 bigleo（楼主）#

主要是现去搜索，费时间又占用大量的上下文，还不一定理解得正确，Token 其实是小事。

🔗 相关话题#

【避坑征集】想征集大家使用AI编程中遇到的问题
多个大模型开发感受
现在大模型这么火，大家都讨论的是对于开发的帮助，各位有碰到AI结合项目管理的么
关于ai编程的Align问题
一直在古法编程，请问佬友们现在AI Coding已经到哪个阶段了？

整理于 2026-06-11 | 原始链接：https://linux.do/t/topic/2375814

微软开源的一键配置工具：把新装的 Windows 系统自动装好全套开发环境

Thu, 11 Jun 2026 00:00:00 GMT

微软开源的一键配置工具：把新装的 Windows 系统自动装好全套开发环境#

来源： 微信公众号（南烛推荐） 发布日期： 2026年6月 原文链接： https://github.com/microsoft/WindowsDeveloperConfig

概述#

微软开源的 WindowsDeveloperConfig，一条命令把新电脑配成开发机。旨在帮助开发者通过一条命令自动化配置 Windows 开发环境，将刚装好的纯净 Windows 系统变成开箱即用的开发工作站。所有配置均为声明式、幂等（可安全多次运行），而且经过 CI 测试。

三种配置方案#

1️⃣ 完整的开发工作站（Windows Dev Config）#

最全的一套，非交互式一键跑完，把全新 Windows 11 变成无干扰开发机。自动安装的包括：

类别	工具
终端	PowerShell 7、Oh My Posh、Cascadia Mono NF 字体
版本控制	Git、GitHub CLI
编辑器	VS Code
开发框架	.NET SDK 10、Python 3.14 + uv、Node.js
系统增强	PowerToys
子系统	WSL + Ubuntu

系统层面优化：

自动开启深色主题、开发者模式、长路径支持
文件资源管理器优化
终端默认配成 PowerShell 7 加 Cascadia Mono NF 字体
WSL 自动配好并装 Ubuntu（启用 WSL 需要重启，脚本会在重启后通过 RunOnce 任务自动继续跑完剩下的配置，无需手动干预）

2️⃣ WSL 命令行环境（WSL Comfort）#

专注打磨命令行体验，支持交互式和非交互式两种跑法：

可自选用 zsh 或 bash 作为默认 Shell
可选装 Starship 提示符、Homebrew
现代 CLI 替代工具：fzf、rg、bat、eza、zoxide
Windows 端会配好带 Cascadia Code Nerd Font 字体的美化版 Windows Terminal 配置文件

3️⃣ 单语言工作负载#

目前支持以下语言，每种都有对应的 install.ps1 脚本，跑完自动刷新当前会话的 PATH：

TypeScript	PHP	.NET	Go	Java	Rust	Python	WinForms	WinUI 3

⚠️ 注意事项#

底层依赖 Windows 的包管理器命令 winget configure
关键坑： 在非管理员权限下运行，必须提前装好 Microsoft Visual C++ Redistributable 运行库，否则会报内部错误
WSL 安装如果在虚拟机里跑，需要确认虚拟化支持（VT-x/AMD-V 或嵌套虚拟化）已经开启

项目地址#

🔗 https://github.com/microsoft/WindowsDeveloperConfig

整理于 2026-06-11

总结了几条 AI 编程的关键技巧

Thu, 11 Jun 2026 00:00:00 GMT

总结了几条 AI 编程的关键技巧#

来源： 微信公众号「雨飞AI笔记」 发布时间： 2026年6月7日 19:57（山东） 原文链接： mp.weixin.qq.com

很多人用 AI 编程，只会选择一个模型，一条路走到黑，浪费了大量的 token 还不一定能出结果。以下几条使用下来非常有价值的技巧，帮你节省 tokens。

1️⃣ 不要在一个对话中切换模型，重开新的对话#

在一个对话中切换模型会导致之前的缓存机制失效，每次切换都需要重新缓存，浪费大量的 token 和算力。

2️⃣ 上下文窗口保持在 60% 以内#

根据实际经验，以 GLM 为例，上下文占用超过 60% 的时候，模型效果会严重崩坏。因此要想省钱就最好明确给 AI 的上下文，必要时可以让 AI 自己压缩历史记录。现在主流的工具比如 CC、Codex 也都有自动压缩功能可以开启。

3️⃣ 规则文件、项目文件不宜过长#

太长的项目文件其实 AI 并没有真正理解，一般来说规则文件在 200 行以内效果最好。像 CC、Cursor 他们内置的提示词也基本在 4-6k 的 token，添加太多的规则，反而让低级模型不明白如何处理事情，所有命令都需要依靠顶级模型，费钱费时。

4️⃣ Skills 并非越多越好#

不管是 CC 还是 Cursor 这种工具，Skills 越多，占据的上下文就越多，也容易引发 Skills 选择错误，造成语义冲突，甚至部分 Skills 根本没有使用过也占据了 token。

整个项目建议的 Skills 不要超过 20 个，以 10 个左右为宜
如果是 Agent 类工具（如龙虾或 Hermes Agent），单个 Agent Skills 数量建议控制在 20-50 个以内

5️⃣ 善用 CLI 命令和脚本#

并非所有的任务都适合用 AI 进行处理，有的时候 CLI 命令反而可以更稳定地得到结果，也不需要浪费大量交互的 token。

目前主流的通信渠道（飞书、企微等）都提供了 CLI 接口，可以让 AI 调用这些接口去完成任务，效果也会更好。另外，也可以部署 crontab 定时任务，综合各类工具的优势，实现最优解。

📌 核心原则：奥卡姆剃刀#

在机器学习领域有一个著名的奥卡姆剃刀原理，核心就是「如无必要，勿增实体」。AI 编程也是如此，能用精简语言描述的内容，就不要用复杂、冗余的描述。

整理于 2026-06-11

老哥们新改了一版简历这次有啥大毛病吗

Thu, 11 Jun 2026 00:00:00 GMT

老哥们新改了一版简历这次有啥大毛病吗#

来源：LINUX DO - 非我莫属 发帖时间：2026-06-04 发帖人：androido 数据：577 浏览 · 26 赞 · 21 条回复 · 标签：纯水, 快问快答

帖子原文#

@androido (androido) · 2026-06-04 05:51

image 702×984 329 KB 上次的已读不回麻了

（注：楼主附了一张简历截图，求职者为技术岗，简历内容密集，含个人信息、技术栈、项目经验等）

全部评论（20条）#

#2 @626 (NumPy)#

2026-06-04 05:52

样式上字太多，“恶心”得一塌糊涂，还需要在优化优化内容上不做评价

#3 @thornLinux (微风放纸鸳)#

2026-06-04 05:55

来给我说一下,项目中是如何保证数据一致性的; ps:这是我比较喜欢问的

#4 @LYOUL (LYOUL)#

2026-06-04 05:55

https://www.codecvcv.com/ 佬友可以用这个网站优化一下排版，选个好看的模板改成自己的
🔗 https://www.codecvcv.com/

#5 @Flyingpen (Eevee)#

2026-06-04 05:56

可以保留这一份，作为单页的。但我建议你做一份多页的，至少3页，纯优化排版。字那么多，甚至还有没写完的部分吧，单从内容上还不够。所以需要一个多页的，好好排版，技术栈之类的用图标、图表、进度条等，缩减文字含量。

#6 @626 (NumPy)#

2026-06-04 05:57

Eevee: 一份多页的同意这种做法，以附录的形式，感兴趣的人会要过来看的

#7 @LM_1997 (离者悲名)#

2026-06-04 05:58

建议修改下排版，现在最大的问题是排版，用WPS简历，或者其他工具都行，现在这个排版点开确实看不下去内容，就更没有下一步了

#8 @amufeng#

2026-06-04 06:01

技术佬的简历基本都是这样，密密麻麻全是说的各种技术。选三个重点项目即可，面试的时候可以展开说

#9 @Flyingpen (Eevee)#

2026-06-04 06:03

#精华比如这里。善于发现并解决问题，这个基本上99%的简历都有。但如果多加一句——对数个开源项目提出 github 优化合并请求，均得到认同。对新技术保持持续关注和学习热情，也是老生常谈。如果多加一句——使用 rss 并持续关注openai、claude 等国内外尖端技术信息。证明你是落到实处的。之所以提出这一点，是因为这几句话就在开头第一段。这是开门印象分。很重要。个人建议，可能有不对的地方，请包涵。

#10 @chenxiaopa (陈小爬)#

2026-06-04 06:05

感觉密密麻麻的，颜色也很单调，弄成两页会不会好一些

#11 @baixb123#

2026-06-04 06:11

找一个自己喜欢的latex模版，直接让ai来优化后自动编译自己调格式还是挺烦的

#12 @Nan0623 (Nan)#

2026-06-04 06:11

github上有好多模板的，我前几天刚做了一份简历，佬可以去找一下

#13 @Sniper_cccc (傻子是心痴)#

2026-06-04 06:13

技术栈为啥加粗？就项目加粗就好了做好排版换行或者直接markdown搞一份然后导出成PDF的文字也有点太多了

#14 @wlxzz (网络小渣渣)#

2026-06-04 06:33

没什么太大毛病，只不过互联网的时代已经过去了

#15 @tgj123 (t3060106756)#

2026-06-05 01:55

先办排版问题改美观一些，内容太多读都不想读

#16 @litj (乡里别)#

2026-06-05 01:59

其实大差不差的，但是没有突出你的亮点；没看到你的邮箱不知道是不是被你打马赛克了；如果有linux.do后缀的邮箱写上去的话，你的面试机会、成功率至少增加90%

#17 @birdfly (饭桶菜鳥)#

2026-06-05 02:10

个人建议，如果英语只有四级的话就不要写了，如果六级没问题可以写六级，不然就是提醒别人我六级没过

#18 @mqq (Leo)#

2026-06-05 02:14

分条目的字体大小要和内容的字体大小分开

#19 @leyfung (leyfung)#

2026-06-05 02:17

用我的项目，优化一下美观度吧，下载安装就能用：jlifeng/JobPilot

#20 @androido (androido)#

2026-06-05 02:45

最新消息有一个面试了在山东济南全栈开发

#精华简历修改建议要点：

1. 格式与排版

字太多、太小，标题和正文不能用同一个字号
应聘岗位、顶部最大（字号层级要分明）

2. 个人优势

放到最后写

3. 专业技能

不要写太多，不要用长句，要用短句和短语
示例写法：
- 熟练使用 Claude Code 等 AI 工具
- 熟悉 java、html5 等语言
- 熟悉 MySQL、Redis 数据库
- 熟悉常见的数据结构和算法
- 熟悉 Linux 系统编程
- 熟悉…
说明：只要这些字往那一写，面试官就知道大概干嘛的了，如果他想知道深入的，他会问（虽然一般问这块比较少），还能引出问题：“我看你说熟练使用 Claude Code 等 AI 工具，那你用过哪些 skill，自己写过什么 skill 吗，skill 是怎么发挥作用的，他和 MCP 有什么区别”

5. 项目内容

项目内容太多了，这两个面试官一看标题就知道是网上随便找的玩具项目，抄起来，背背项目知识点、提问点，现在有 AI，速成一个现有项目就是几天的事情。（不是说佬你的一定是抄的，只是这种现象很普遍，而面试官又不可能清楚分辨出哪些是抄的，哪些是写的，只是凭感觉认为）
可能你觉得里面写的很好，真的很有技术点、设计也很好（说实话，毕竟是很多面试商家打磨的，项目本身肯定是不错的，很多人自己写写不出来的），但是事实上，很多面试官根本不会这么想。

6. 项目功能描述

项目不要写太多功能，看个项目标题就大概能猜出功能了
个人介绍的时候也可以说两句做了什么东西，功能没什么提问点，重点不是你做了什么，而是你怎么做的
个人项目主要写”有提问点的技术细节”，让面试官一看到这个就想问你
我当时根本没有什么项目简介、技术栈，就是一行项目日期、标题、类型，下面就是几个”使用实现 ”、“基于实现 *“，比如：
- “采用基于无锁队列的事件分发模型来减少锁带来的性能消耗”
- “采用零拷贝技术进行文件传输”
就是两个提问率比较高的点”无锁队列实现”和”零拷贝”，经常被问，我也会准备好对应的回答
个人项目就找技术提问点就行了，记住目的不是为了”介绍项目”，面试官根本不关系（关心），只关心里面的技术点，你的目的也就是突出这些提问点，引导面试官关注，让他问你
对于实习项目，才会功能和介绍结合，面试官会好奇其他公司在做什么，且是个实际项目，提问率比较高

7. GitHub 链接

如果有 github 链接，直接在项目底部贴一个链接，要比其他什么乱七八糟的描述更有说服力，就算面试官不会看也要有
如果面试官真的看了，看到了你的 github 主页、项目仓库 README，完整详细的 commit 记录，这能说明很多东西
如果让我面试一个人，他的 github 小绿点从他大一就开始亮起且频率不错，commit 记录完善，他在我心中就已经是一个比较优秀的形象了，这种人大概率上是不会差的

互动数据：578 浏览量 | 26 赞 | 1 链接 | 18 用户

页码：21 / 21

核心要点总结#

要点	具体建议
排版是第一优先级	密密麻麻的文字直接劝退面试官；使用 WPS 简历、codecvcv.com、GitHub 模板、LaTeX 等工具
做多页版本	单页 + 多页（至少 3 页）双版本；多页版可用附录形式展示技术细节，技术栈用图标/图表/进度条
内容精简	选 3 个重点项目重点展开，面试时可以深入聊
自我评价要具体	不要写”善于解决问题""关注新技术”等空话，必须附带具体事例（如 GitHub PR、RSS 订阅源）
开门印象分	第一段是面试官最先看到的，空泛表述会直接降低好感
技术栈呈现	用图标、图表、进度条等可视化方式，缩减文字含量；不要滥用加粗
格式	Markdown 编写 → 导出 PDF，或用 LaTeX 模板 + AI 自动编译
英语等级	四级不要写（反而暴露没过六级），六级才值得写
邮箱	linux.do 后缀邮箱可能加分
面试题预备	被问”项目中如何保证数据一致性”的概率很高

抓取时间：2026-06-05 12:07 帖子链接：https://linux.do/t/topic/2303618 原始 JSON 数据：54KB，包含全部帖子 HTML 和元信息

重磅！Anthropic内部Skills经验公开了！

Thu, 11 Jun 2026 00:00:00 GMT

重磅！Anthropic内部Skills经验公开了！#

来源： Datawhale（微信公众号） 作者： Anthropic团队 发布时间： 2026年6月7日 22:03 浙江 原文链接： https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills

Anthropic 自己内部是怎么用 Claude Code Skills 的，这次终于公开了。

他们把内部团队的用法做了一次完整复盘：Skills 分成哪 9 类、哪类最值得花力气、怎么写才真的有用。这些经验之前只在 Anthropic 内部流转，现在一次讲清。

今天把这个经验帖的核心干货给你梳理清楚。

一、先把 Skill 理解对#

Anthropic 先纠正了一个很常见的理解。Skill 不只是几段提示词，它更接近一个围绕任务组织起来的文件夹。

这个文件夹里可以放 SKILL.md，也可以放参考文档、脚本、模板、示例、hooks，甚至放会被后续任务继续读取的数据。Claude 调用 Skill 时，拿到的其实是一套完成任务所需的工作材料。

这个定义很重要。因为很多团队真正缺的，从来不是”再补一段提示词”，而是把那些已经验证过的做法、容易错的细节、常用脚本和固定流程，一次整理好，后面反复复用。

二、Anthropic 把内部 Skills 归成了 9 类#

Anthropic 盘了一遍内部的 Skills，最后大致分成了 9 类。这 9 类连起来看，其实很像一条完整的软件工作流，从补知识到写代码，再到验证、部署、排障和运维。

前三类：给模型补知识、补验证、补数据#

第一类是 library 和 API reference，给模型解释某个库、CLI 或 SDK 在团队内部到底该怎么用，把容易用错的规则和 gotchas 写清楚。

第二类是 product verification，负责判断产出有没有真的工作，比如在无头浏览器里完整跑一遍注册和结账流程。Anthropic 明说这类对输出质量提升最明显，值得让工程师专门花一周打磨。

第三类是 data fetching and analysis，连着数据仓库和监控系统，把取数方法、字段约定和常见分析路径封装好，模型不用再去猜表结构和字段名。

中间三类：开始接住团队里的日常流程#

第四类是 business process and team automation，把重复发生的团队流程压成一个命令就能跑的工作流，比如只输出相对昨天增量的 standup，或固定格式的周报。

第五类是 code scaffolding and templates，生成那些有固定骨架、但又带着大量自然语言约束的代码，比如新 service 或迁移文件。

第六类是 code quality and review，让代码尽量符合团队的质量标准。典型例子是拉一个”新鲜视角”subagent 来挑错的 adversarial-review，这类能力还能做成 hook 接进 CI。

后三类：已经连到生产环境了#

第七类是 CI/CD and deployment，把代码从开发态推到上线态。比如 babysit-pr 会盯完一个 PR 的全过程，deploy-<service> 会把 build、放量、错误率对比和回滚条件串成一条链路。

第八类是 runbooks，入口不是”我要写什么”，而是”现在出了什么症状”。报警、Slack thread、request ID 进来，它负责映射到该用哪些工具、查哪些路径，最后给出结构化结论。

第九类是 infrastructure operations，处理资源清理、依赖治理和成本排查这类例行操作。这些动作常带破坏性，所以 Skill 里要写清 guardrail，先通知、再确认，最后才真正执行。

三、Anthropic 真正强调的，不只是”会写”，更是”写对”#

好的 Skill，往往都很聚焦#

Anthropic 说得很直接，最好的 Skill 往往都很聚焦。能清楚落进某一类里的 Skill，通常更稳；试图同时覆盖太多目标的 Skill，反而更容易把模型带乱。

所有类型里，他们最看重「验证」#

在所有类型里，Anthropic 特别强调 verification。因为模型最容易给人一种”已经做完了”的错觉，而真正容易掉链子的地方，恰恰是最后那一步验证。

原文甚至建议，值得让工程师单独花一周，把验证类 Skill 做到足够好。

他们还给了两个非常实用的建议：

让 Claude 录下自己测试过程的视频，这样你能清楚看到它到底测了什么。
在关键节点加程序化断言。状态有没有变化，事件有没有真正落库，最终页面是不是到了目标状态，都尽量不要只靠”看起来差不多”。

真正有价值的内容，往往是 gotchas#

Anthropic 对 Skill 里的内容优先级也讲得很清楚。最有信号量的部分，通常不是通用步骤，而是 gotchas。

因为 Claude 本来就会写代码，也会读代码库。那些”默认它也会做”的东西，写进 Skill 里只会增加上下文，不一定增加价值。

真正值得写的，是那些会把模型从默认思路里拽出来的细节：

subscriptions 表是 append-only，要找最高 version，不能只看最新 created_at。
同一个字段，在 API gateway 里叫 @request_id，到了 billing 服务里叫 trace_id。
staging 返回 200，也不代表 Stripe webhook 真处理成功了，还得去看 payment_events 里的真实状态。

四、Skill 到底该怎么写#

1. 别把显而易见的话再写一遍#

Skill 不是给人看的摘要，它要补的是模型默认拿不到、或者默认容易走偏的信息。Anthropic 提到过一个前端设计 Skill 的例子——它的价值不在于教 Claude 怎么写前端，而在于补充团队通过和客户反复迭代后沉淀下来的”设计品味”和避坑点。

2. SKILL.md 更像目录，不该写成大杂烩#

更好的做法是让 SKILL.md 做目录和路标，把具体资料按需分发到别的文件里：

任务卡住了，再去读 stuck-jobs.md
API 的函数签名和用法示例，拆进 references/api.md
模板放进 assets/
脚本、参考资料、例子分目录放好

这套做法就是 progressive disclosure——文件系统本身，也是一种上下文工程。

3. Skill 不要写得太死#

给 Claude 关键规则，但也要给它足够的适应空间，不然 Skill 一复用，就容易在别的具体情境里卡住。

4. setup 要提前想好#

很多 Skill 真跑起来时，会缺一些来自用户的上下文。原文建议把这类配置放进 config.json，如果配置还没建好，Claude 就先问用户。

5. description 要直接服务触发#

description 是写给模型看的，决定 Skill 会不会被触发。它不是摘要，而是触发条件说明。用户可能会说什么关键词、上传什么文件、什么场景下应该激活这个 Skill，都应该直接写进去。

五、Skill 用深之后，会先长出记忆、脚本和 hooks#

记忆#

像 standup-post 这种 Skill，可以把每次输出都记进 standups.log，下次运行时先读历史，再判断今天和昨天相比到底变了什么。可以用 append-only 文本或 JSON，也可以用 SQLite。

脚本#

Anthropic 的判断很明确——能给 Claude 的最强工具之一，其实就是代码本身。预置常用的数据抓取函数、分析函数或操作脚本，Claude 就能把更多回合花在”怎么编排”和”下一步做什么”上。

on-demand hooks#

它们只在 Skill 被调用时生效，而且只在当前会话里存在。例如：

/careful：拦住 rm -rf、DROP TABLE、force-push、kubectl delete 等高风险操作
/freeze：阻止对指定目录之外的 Edit 和 Write，适合排障时防止顺手改坏别的地方

六、当团队开始大量用 Skill，后面就是分发和治理#

两条主路线#

repo 内 check-in：把 Skill check in 到 repo 里的 ./.claude/skills，适合规模不大的团队。
插件 marketplace：用内部的 Claude Code Plugin marketplace 上传和安装，团队一变大优势更明显。

治理流程#

Anthropic 没有一上来就搞中央审批。更常见的方式是：谁有 Skill 想给大家试，就先传到 GitHub 里的 sandbox 文件夹，再发到 Slack 让其他人试用。等这个 Skill 真有了 traction，再由 Skill owner 提 PR，正式移进 marketplace。

Skills 之间也可以互相组合#

比如一个文件上传 Skill，再有一个 CSV 生成 Skill，后者生成完文件后，再去调用前者完成上传。只要在 Skill 里直接引用另一个 Skill 的名字，模型在安装了它们的前提下，照样能把链路串起来。

使用度量#

Anthropic 会用 PreToolUse hook 记录公司内部的 Skill 使用情况，了解哪些 Skill 热门、哪些触发明显不足。

写在最后#

Anthropic 在文章结尾提到一个细节：他们内部最好的 Skills，一开始往往只有几行字和一个 gotcha，用得越多，才补得越完整。

这句话基本可以当成上手指南。写 Skill 不用追求一步到位，先把验证方法写清楚，把真正踩过的坑记下来，脚本、记忆、hooks 和分发，等用起来之后再慢慢补。

如果你也在用 Claude Code，不妨从手头最常重复的那个任务开始。先写几行说明，加上一个 gotcha，剩下的交给时间和使用频率。

本文转载自微信公众号 Datawhale，原标题为”重磅！Anthropic内部Skills经验公开了！“，内容有整理。

阿里巴巴开源AI代码审查命令行工具；一键安装AI工具；AI课件转考试复习助手

Thu, 11 Jun 2026 00:00:00 GMT

阿里巴巴开源AI代码审查命令行工具；一键安装AI工具；AI课件转考试复习助手#

原创：科技九点半 · 每日AI新工具
2026年6月8日 10:12 福建
关注我，记得标星⭐️不迷路哦～

✨ 1: Open Code Review —— AI代码审查命令行工具#

Open Code Review 的核心价值在于把”工程确定性”与”AI Agent能力”结合起来做代码审查：它本质上是一个面向 Git 变更的 AI Review CLI，来自阿里巴巴经过大规模真实场景验证的内部能力，强调在大改动场景下依然保持完整覆盖、定位准确和质量稳定；与纯自然语言驱动的通用 Agent 不同，它通过确定性的文件筛选、关联文件打包并发审查、按文件特征精细匹配规则、独立的评论定位与反思模块来保证”不会错”的环节，再让 Agent 专注于动态决策和上下文检索（如读取全文件、跨文件搜索、结合上下文深度分析），从而输出带行级定位的结构化审查意见；在使用形态上，它既可作为本地 CLI 审查工作区/分支/提交，也能以 JSON 结果接入 GitHub Actions/GitLab CI，还能无缝嵌入 Claude Code、Codex、Skills 等智能编码工作流；同时它支持分层优先级的规则体系（命令行/项目级/全局级/系统默认）、可定制 include/exclude 过滤策略与规则模板，兼顾通用性和团队个性化标准，另外提供会话 Viewer、可观测性遥测（OpenTelemetry）及基础安全防护（如 Viewer Host 白名单防 DNS Rebinding），整体上是一个偏工程化、可扩展、可落地到团队协作和自动化流水线的专业 AI 代码审查方案。

地址： https://github.com/alibaba/open-code-review

✨ 2: EchoBird —— 跨平台AI部署与应用管理平台#

EchoBird 的核心价值是把”AI 工具部署难、模型配置碎片化、跨设备环境不一致”这几个痛点打包成一个统一的桌面平台：它围绕一个可复用的模型中枢（Model Nexus）构建，支持 OpenAI、Anthropic、本地 LLM 与 API 路由等多模型源，一次配置即可在全局复用，并提供延迟检测来降低选型成本；在此基础上，项目提供四个互相联动的核心场景——用安装与修复 Agent 通过对话式方式自动安装/排障主流 AI 工具（含本地与远程）、一键启用本地 LLM 运行时（vLLM/SGLang/llama.cpp，选择量化后即可启动）、在”My AI Projects”中托管和管理自建 AI 应用/游戏，以及通过 App Manager 对各类 AI/Agent 应用进行一键启动与统一管理，整体形成”配置一次，到处可用”的工作流闭环；同时它采用 Tauri + Rust 实现并覆盖 Windows/macOS/Linux（x64/arm64）跨平台，定位上不仅是下载渠道仓库，还承担 issue 反馈入口，产品信息主要由官网承载。

地址： https://github.com/edison7009/EchoBird

✨ 3: ExamPass Assistant —— AI课件转考试复习助手#

ExamPass Assistant 的核心价值是把分散的课程资料一键转成”可直接备考”的学习产物：它面向期末复习场景，支持将 PPTX、DOCX、PDF（含图像内容识别）统一解析后，自动生成结构化知识导图式复习讲义与可交互自测题页面，重点在于不仅提炼知识点，还会标注考试优先级、构建概念逻辑链，并提供可点击作答、即时判分、错因解析与易错提醒的练习体验；整体以浏览器即开即用为导向，支持公式渲染与打印导出，既适合学生高效自学，也适合教师快速产出练习与作业，同时通过按章节分组处理、全流程扫描提取分析生成、命令式工作流（章节生成/更新/期末模拟卷）和缓存加速机制，形成了一个实用的课程级 AI 备考生产线。

地址： https://github.com/WUBING2023/ExamPass-Assistant

✨ 4: lowfat —— 轻量CLI命令输出压缩工具#

lowfat 是一个面向 AI 编程/命令行场景的轻量级 CLI 压缩工具，核心价值是在命令输出进入智能体前先做”降噪与压缩”，从而减少 token 消耗并尽量保留关键信号；它强调”小而可扩展”的设计理念（单二进制、本地优先、无遥测、可组合管道），内置了对 git、docker、ls、find 等高频命令的分级压缩能力（lite/full/ultra），并支持通过 .lf DSL、Shell、Python 扩展自定义过滤器，适配 Claude Code、OpenCode、Shell、Pi 等多种代理/终端集成方式；同时它不仅提供压缩，还提供可观测性与可运营能力（如 info 查看当前过滤链路、stats/history 统计节省与高价值命令、plugin doctor 做插件健康检查），让用户能围绕自身工作流持续调优压缩强度与插件策略；对比同类工具 rtk，lowfat 的差异在于更少但更聚焦的内置能力、更强的”用户自定义与本地掌控”取向，以及在 README 给出的样例中对 git 类输出表现出更激进的压缩效果，但项目也明确这些数字是场景相关的方向性结果而非统一性能承诺。

地址： https://github.com/zdk/lowfat

✨ 5: dots.tts —— 全连续自回归文本转语音系统#

dots.tts 的核心定位是一个 20 亿参数、全连续（无离散 token）、端到端自回归的高质量 TTS 系统，主打 48kHz 语音生成、零样本语音克隆与多语言泛化能力；它通过”语义编码器 + 文本 LLM（基于 Qwen2.5-1.5B）+ 自回归 flow-matching 声学头 + 冻结 AudioVAE”的连续建模架构，直接从 BPE 文本到声学潜变量逐步生成，实现稳定、自然且具情感表现力的语音合成，并支持常规整句生成与 1T1A 交错式低延迟流式推理；从 README 给出的多项评测看，该项目在 Seed-TTS-Eval 上达到开源 SOTA 平均水平，在 MiniMax 24 语种上取得最高平均说话人相似度（SCA 版本 83.9），在 CV3-Eval 与 EmergentTTS-Eval 的高难和表现力维度也具竞争优势，说明其在可懂度、音色保持、跨语种克隆与表达能力之间做到了较好的平衡；工程侧同时提供完整推理与微调代码、CLI/Python/Gradio 多入口与多种已发布检查点（预训练/SCA/MeanFlow 蒸馏），便于研究和落地，但项目也明确提示高保真克隆存在滥用风险，且在低资源语言上仍有 WER 短板，当前发布重点仍是语音场景而非歌声或通用声音生成。

地址： https://github.com/rednote-hilab/dots.tts

这就是本期的内容，记得标星⭐️点赞，关注我不迷路哦～
每日AI新工具

尝试用 Pi 理念设计订单系统（MVP 实现）

Thu, 11 Jun 2026 00:00:00 GMT

尝试用 Pi 理念设计订单系统（MVP 实现）#

来源：小红书笔记 | OCR 提取整理于 2026-06-11

起因#

朋友做批发生意，有几百个客户微信群，24 小时随时可能有人下单。

下单的方式五花八门——有人发”10 件”，有人发”跟昨天一样”，有人发”加 3 件”，有人先说 8 件过会儿又说”改成 7 件”。每个群的说话习惯不一样，角色关系不一样（有的群老板先报预估数、实际经营者后来说的才算），规格默认值也不一样。

延迟要求不高（凌晨下单早上配送），但需要人 24 小时盯着群。他雇人盯屏幕手敲 Excel，漏单、错单、重复记是常态。而几百个群的量，人工成本越来越高。

第一版我写了 parser——正则匹配数字、规则引擎判断消息类型。写了 2000 行，发现根本兜不住。“加 3 件”是加单，“3 件”可能是新单也可能是回答”你今天要多少”，“后面为准”意味着之前的数字作废。每个群的规矩不一样，规则越写越多，改一个崩三个。

后来想明白了：这些判断本质上是在理解人在说什么，这正是 LLM 擅长的事。于是推倒重来，用 Agent 架构重写——不写 parser，让 LLM 直接理解消息，调 tool 记录结果。

系统分两期：

当前阶段： 订单自动记录 + 复核（LLM 记录，置信度低的标待审查，人工确认）
后续扩展： 转账记录、自动对账、库存跟踪、实时微信接入、Web 看板

为什么选择 Agent Framework#

我日常用 AI 编程助手，从 OpenClaw 到 Hermes，最终一直在用 Pi（一个开源终端 coding agent）。用久了发现它的设计特别好：

功能随加随用——想加新能力？写个 skill 文件，一行注册，零改动已有代码
极度灵活——自定义 tool、自定义 prompt 片段、自定义快捷键，想怎么配怎么配
Harness 完全不知道自己在干嘛——agent loop 就是个简单的 while 循环，发消息给 LLM、调 tool、喂结果。它不知道自己在写代码还是在处理订单，所有业务知识都是注入的。这就是所谓的 “Harness 是空壳，能力通过注册注入”。

朋友的订单系统正好需要这种灵活性——几百个群，每个群画像不同，随时可能加新类型的消息处理。如果写死在代码里，每加一个群就要改一次代码。但用 Pi 的理念：每个群一份画像文件，新群 = 新文件，代码不动。

所以这个项目本质上是：把 Pi 的架构思想，从编程场景搬到了业务数据处理场景。

架构：三层#

整个系统分三层：

1
Gateway（入口）→ Core / Harness（引擎）→ Capabilities（业务）

Gateway#

Gateway 是数据入口，现在读 JSON 文件，以后接微信机器人。它的作用是把原始消息清洗成结构化的 Message 对象。

Core（引擎）#

Core 是引擎，不知道自己在处理什么业务。它只做一件事：把消息给 LLM → LLM 说调 tool 就调 → 结果喂回去 → 循环。

它不知道”订单”是什么，不知道”件数”是什么。搜遍 core/ 目录，找不到任何业务词汇。这意味着：换一个行业（物流、餐饮、零售），core/ 一行不改。

Capabilities（业务层）#

Capabilities 是业务层，放所有具体的东西——订单模型、数据库、5 个 tool、群画像。加新功能 = 写新文件 + 注册，永远不改已有文件。

core/ 目录结构#

1
core/                    # 无业务，通用引擎
2
├── agent.py             # while 循环：发消息～调 tool～喂结果，继续
3
├── registry.py          # tool 注册表，bootstrap 自动扫描 tools/ 目录
4
├── session.py           # 对话上下文管理
5
├── llm.py               # LLM 接口，抹平不同模型的行为差异
6
├── events.py            # 事件总线
7
├── types.py             # Message、ToolCall 等基础类型
8
└── config.py            # 配置开关
9

10
capabilities/            # 纯业务，只有 Python 标准库
11
├── domain/models.py     # 领域模型
12
├── store/               # SQLite 存储
13
├── tools/               # 5 个 tool：下单、转账、退货、价格变动、查询
14
├── context/             # 提示词：行业知识 + 角色设定
15
├── memory/groups/       # 群画像 + index.json 路由
16
└── extensions/          # 扩展插件（消息分段、脱敏、审查、审计）

Show moreShow less

扩展性设计#

系统的扩展性不是靠复杂的插件框架，而是靠 一致的注册模式。每种扩展方式都是同一个套路：写文件 + 注册。

5 种扩展方式#

1. 加新 Tool —— LLM 可调用的能力#

启动后 LLM 自动知道有这个 tool 可用。

Tool 的本质： Tool 是 LLM 可以主动调用的能力。LLM 读到消息后自己判断要不要调、调哪个、传什么参数。代码不做这个判断——没有 if/elif 消息分类，没有正则匹配。这也是为什么不需要 Parser——LLM 就是 parser。

2. 加新群画像 —— per-group 知识注入#

capabilities/memory/groups/新客户群.md → 新画像

系统处理这个群的消息时，自动加载画像注入 prompt。

画像告诉 LLM 这个群的特殊规律——谁说了算、门店叫什么、默认规格是什么。不同群的画像完全独立，互不影响。

3. 加新 Extension —— 数据管道中的变换环节#

capabilities/extensions/sanitizer.py → 新文件

Extension 是数据管道中的变换环节。它改数据本身——输入一种格式，输出另一种格式。数据必须经过它，它是处理链上的一环。

现在实现了 session_grouper.py（按天分段），规划的 Extension：

Extension	输入	输出	作用
session_grouper	Message 列表	Segment 列表	按天分段，让 LLM 看到完整上下文
sanitizer	Message	Message	脱敏（手机号、地址脱敏后继续处理）

Extension 的设计原则： 纯函数，零 core 依赖。输入是什么、输出是什么，可以独立测试。不 import core/ 的任何东西。

4. 加新 Gateway —— 换数据入口#

Gateway 只做一件事：把原始数据转成 Message 对象。它不碰 core/，不碰 LLM。在 main.py 里换成新 gateway，整个系统就走新数据源了。

这意味着：从 JSON 文件 → 微信实时消息 → 钉钉 → 飞书，只换 Gateway，其余不动。

5. 换业务 —— 换 capabilities/ 目录#

如果不用来处理批发订单了，改成处理餐饮外卖、物流调度、客服工单：

domain/models.py —— 换成新的领域模型
tools/ —— 换成新的 tool
context/business.md —— 换成新的行业知识
memory/groups/ —— 换成新的客户画像

core/ 不动。8 个文件原封不动。

3 种集成方式（来自 Pi 的设计）#

1. Skill —— 领域知识 + 操作流程的封装#

Skill 是 Pi 的核心扩展机制。一个 Skill 是一个完整的操作指南——什么时候触发、怎么做、注意什么。它不是代码，是一份结构化的 markdown。

1
skills/
2
├── order-review/SKILL.md    # "复核订单"技能
3
└── batch-import/SKILL.md    # "批量导入"技能

Skill 文件里包含：

触发条件 —— 用户说什么话时加载这个 skill
操作步骤 —— 第一步做什么、第二步做什么
知识参考 —— 相关的 business.md 片段、tool 用法
检查清单 —— 做完后验证什么

比如”复核订单”skill 会告诉 LLM：先查今天所有待审查订单 → 逐条跟原始消息比对 → 确认或修正。这些流程如果写在 role.md 里会很长，按 skill 按需加载才合理。

Skill 和 Tool 的区别： Tool 是一个原子操作（记录一笔订单），Skill 是一个多步骤流程（复核今天所有订单）。Tool 是代码，Skill 是 prompt。

2. Context —— 动态 prompt 片段#

Context 是在运行时动态注入的 prompt 内容。比如群画像是 per-group 的 context，每天的订单汇总可以作为当天的 context 注入。

1
context/
2
├── business.md       # 静态，行业知识（固定不变）
3
├── role.md           # 静态，角色设定（固定不变）
4
├── [运行时注入]
5
│   ├── 群画像        # 动态：per-group 知识
6
│   └── 今日汇总      # 动态：per-session 数据

这种设计来自 Pi 的 promptSnippet 机制——harness 控制 prompt 的拼接结构（什么放前面、什么放后面），tools/skills/memory 填充具体内容。每个模块只知道自己该贡献什么，不知道最终 prompt 长什么样。

3. EventBus —— 模块间松耦合通信#

模块之间不直接调用，而是通过事件总线间接通信。Tool A 记录了一笔订单后，发一个 order_recorded 事件。审查模块、审计模块、通知模块各自订阅这个事件，做自己的事。Tool A 不知道谁在监听，监听者也不知道谁发的。

Extension 和 EventBus 的区别：

Extension 改数据（消息分段、脱敏），是数据管道的一部分
EventBus 不改数据，是事后通知（“这件事发生了，谁关心谁处理”）

review_guard 表面看像 Extension（它要改订单状态），但本质是”收到 order_recorded 事件后执行一段逻辑”，属于 EventBus 订阅者，不是管道环节。

踩过的模型坑#

qwen3.6 的 tool calling 死循环#

同一段消息被处理 5 次，DB 里出现大量重复。去 LangSmith（LLM 可观测性平台）看 trace，发现 assistant message 同时带了分析文字和 tool_calls。下一轮 LLM 看到自己写了”需记录”，以为还没处理完，就又调一遍。

修复一行： 有 tool_calls 时丢弃 content。

不同模型对同一 API 的行为不同——有些 content="" + tool_calls，有些同时返回。做 agent framework 必须在 harness 层统一。

qwen3.6 的 thinking 模式#

默认开启，53% 的 token 花在内部推理上。简单 4 条消息从 9 秒变成 33 秒。加 enable_thinking: False 解决。

通用规则：thinking 适合复杂推理，但 tool calling 场景不需要。

max_tokens 截断#

max_tokens=2048 太小，输出被截断，LangSmith 出现幽灵 trace。增大到 4096 解决。不同模型的 token 消耗差异大，宁大勿小。

持续质疑复杂度#

每加一个抽象层之前问：真的需要吗？

Parser 基类？ —— 不需要，LLM 直接理解
Tool 基类？ —— 不需要，register() 函数就够了
状态机？ —— 不需要，agent loop 是简单 while 循环
EventBus hook chain？ —— 暂时不需要，只有 1 个消费者（YAGNI）
门店名映射表？ —— 不需要，群画像里写清楚就行

知识分层#

层	内容	谁来写	变化频率
business.md	行业常识：规格表、交易流程	人写，很稳定	低频
role.md	角色关系、谁说了算	人写	低频
group profile	群画像	分析数据后定	中频
tool description	什么时候调、历史	写 tool 时一起写	低频
role.md	角色设定：你是谁	人写	低频

每层各管各的，不交叉：

群画像里不写 tool 名（tool 怎么用由 tool 自己告诉 LLM）
tool description 里不写具体人名（避免硬编码）
business.md 里不写某个群的行为（它是行业通用的）

Prompt 排列顺序的影响#

现在系统给 LLM 的 prompt 按这个顺序排列：

business.md（行业常识，固定不变）
role.md（角色设定，固定不变）
群画像（per-group 知识，半固定）
当天的消息（每次不同，变化最大）

为什么这么排？两个原因。#

注意力 U 型分布#

斯坦福和 Meta 的论文 “Lost in the Middle” 发现，LLM 对长文本的注意力呈 U 型分布——开头和结尾注意力最高，中间最低。关键信息放中间时，准确率下降 20% 以上。

我们把不变的行业知识放最前面（先建立”这个行业的常识”），变动的消息放最后（LLM 最后读到、马上处理），中间放群画像（它才是理解上下文的关键知识）。

KV Cache 复用#

这是个工程优化。LLM 处理每轮对话时，要把所有历史 token 重新算一遍。但前面没变的部分，计算结果可以缓存复用。

排列规则：越不常变的放越前面。

business.md 几乎永远不变，缓存利用率最高
消息每次都变，放最后

如果倒过来，消息放中间、群画像放最后，每次新消息进来，群画像的缓存就失效了，白白重算。

实际效果： 固定前缀（business.md + role.md + 群画像）大约 2500 token，消息平均 500-2000 token。前缀不变时，每轮省掉约一半的计算量。

简单记：不变的放前面，常变的放后面，最重要的放开头和结尾。

⚠️ 目前 agent loop 是单轮处理（一段消息一个 session，跑完就结束），所以 KV Cache 复用还没真正生效。等后续改成多轮交互式 gateway（LLM 和人来回对话），这个排列顺序的收益才会体现。

Reviewer Skill —— 用清单约束设计#

每次写完一个阶段，跑一遍 10 条审查清单：

🔗 解耦 —— grep "from capabilities" core/ 必须为空
📌 SSOT —— 每个概念只定义一次
🔌 扩展性 —— 加功能只加文件不改已有，bootstrap 自动扫描
🕳️ Harness 空壳 —— core/ 零业务字符串
🧠 输入信任 LLM —— 输入侧不用 enum
📊 行业知识纯度 —— business.md 换个行业内容仍成立
🏷️ Tool 意图命名 —— action+target（record_order 不是 create_order）
🚫 代码不做 LLM 该做的事 —— handler 里没有正则分类
🌐 通用性 —— 换业务只改 capabilities/
✅ 真实数据验证 —— 用真实消息验证，不是编测试用例

全文约 4554 字 | 阅读需 15 分钟

面试十几家 Agent 岗位，整理了面试题～

Thu, 11 Jun 2026 00:00:00 GMT

【面试拷打】面试了十几家 Agent 岗位，整理了面试题～#

来源：LINUX DO | 作者：guava_16 | 2026-06-11 原文：linux.do/t/topic/2365650

上个月公司裁员，开启了前端面试之旅，一路坎坷，转而学习了一些 AI 课程，面试了十几家 agent 岗位（中间可能穿插偏向前端和全栈的岗位），面试过程都录音了，然后让 AI 整理了一下面试官提问的问题，分享给各位佬一起学习学习～

ML 公司#

AI XX 系统主要是做什么的？
LangChain / LangGraph 主要用了什么 AI 技术？
有没有了解过像 Manus 这种通用 Agent？
这些通用 Agent 一般分几层功能？
有没有构建过多智能体（Multi-Agent）架构？
什么是多 Agent？为什么需要多 Agent？
什么场景下需要多 Agent 架构？
单个 Agent 其实也可以分配多个职能，为什么还要多 Agent？
多 Agent 主要是为了解决什么问题？
你这个系统之前用户量有多少？日活有多少？
Agent 的使用量是多少？Token 消耗量大概多少？
有没有考虑过怎么节约 AI 成本？
做了哪些成本优化方案？最终降了多少成本？AI 投入前后带来的收益有多少？

KJ 公司#

Claude Code 的多层架构是怎么做的？
PS 网页版实现方案？Canvas 无限画布是怎么实现的？
WebAssembly 有了解过吗？
Docker 和 K8s 的关系？Docker 中容器和镜像的关系？怎么进行挂载的？
K8s 中多个服务怎么进行通讯？
怎么进行团队的管理？怎么推动项目进度？
Express 的底层原理？如果让你设计实现怎么做？
入职后如何快速上手分配的业务需求？简说思路
说一说在职业中比较具有挑战性的问题

JR 公司#

介绍一下你的 AI 项目的架构情况？
为啥选择 LangChain、LangGraph？选型的依据是啥？
抽象通用 AI 能力模块做了什么？
AI 调用工具失败了怎么解决？
简单介绍一下 RAG 的流程？
怎么加速 RAG 的检索过程，有啥策略？
向量库目前的数据量？向量库使用的是啥？选型依据？
大模型的选型逻辑？
（政策文件场景下）怎么确认召回的数据准确性？
你们上下文压缩的策略是什么？
追问：上下文压缩时，如果大模型能力问题压缩质量有问题怎么解决？
有了解之前 Claude Code 泄露的事件？有没有研究过源码？
Claude Code 的上下文治理是怎么做的？核心循环流程说一下？
多租户的场景下 K8s 怎么部署的？一个租户一个对应 Pod 吗？

TK 公司#

企微 H5 登录流程是怎么做的？
企业微信只能绑定两个域名，多个业务域名怎么处理？
UI 没空出原型，需要你自己设计页面？没有设计稿时你怎么推进？
有没有做过 H5 用户打标签？
用户进入页面后：怎么获取唯一 ID？企微回调里的 ID 同步怎么做？
有没有做埋点？怎么做的？埋点获取哪些数据？
RAG 的检索是怎么做的？
海豚工作流同步数据时：MySQL IO 爆红怎么排查？（场景：三连表、每小时同步、查一个库、插另一个库、插入时报错、IO 爆高）
MySQL 大表优化怎么做？百万级数据后出现慢插入？

YC 公司#

怎么保证数据库和缓存之间的数据一致性？
从 0 到 1 搭建一个项目，怎么设计架构？
你这个 AI XX 系统，如果从架构角度看，分成哪些层？
假设现在让你做一个 xxx 门店的 AI 数字化系统，你会怎么设计？
技术架构：你怎么拆模块？数据怎么流转？技术选型怎么做？
AI 工具出现后，对传统研发工作流造成了很大冲击。你个人或团队有没有相应的 AI 工作流？
如何把 AI 融入开发流程的？有 AI 编程规范吗？
AI 写的代码相对不可控，你们有没有 Code Review 流程？
SSE 断线续传？由于客户端因素断了（如窗口关闭又打开、刷新页面），需要让他继续接收 SSE 流，你们有没有做过？

HJ 公司#

个人一个月 Token 使用量大概是多少？
如果政府项目限制使用国外模型或工具，完全使用国内工具有没有影响？
有没有做过国内外 AI 工具或模型的对比？
同一个模型不同工具，或者同一个工具不同模型，效果差异有没有研究？
没用 AI 和用了 AI 后，你觉得效率提升有多大？按百分比来说，你觉得 AI 能提升多少效率？
你会用什么 AI 工具来完成项目规划、草图、文档和开发？
未来全栈开发需要具备一定架构师能力，你搭框架的整体思路是什么？
传统 XX 业务系统的后端分几层？
你们产品开发完后，最大用户并发数大概是多少？这个高并发项目部署在哪里？
有没有做熔断之类的处理？高峰、限流、缓存、异步队列这些有没有做过？
全栈项目没有测试岗，是怎么测试的？
有没有做过基于 AI 的界面测试？AI 是否能覆盖前端点击、输入、提交等自动化测试？
对未来职业规划是怎么想的？你是想跟着公司的战略方向走，还是自己有明确想法并寻找匹配的岗位？
如果客户是政府单位，要重新定制开发一个软件，包含客户端、APP、小程序，售前已完成调研，项目体量约 50 万，一个月内交付，你如何拆解流程？
如果是资产管理系统，你会如何利用 AI 完成开发和交付？

FN 公司#

Vue 和 React 核心区别是什么？谁性能上限更高？
React 和 Vue 最新版本在做什么？
浏览器发起 HTTP 请求经历什么过程？哪些地方会发生缓存？
找一个印象最深的项目聊聊
SSE 和 WebSocket 分别说说？
AI 时代程序员价值是什么？
你认为自己在编程优点和缺点？
最近学什么？职业规划是什么？

XZ 公司#

你自己的 AI 的开发工作流程是怎么样的？
有在使用什么 MCP 或者 SKILL？
接到一个需求后，你会怎么做？
你的 3~5 年职业规划是怎么样的？
工作中做过比较深刻的事情？

SH 公司（太好了是前端八股！）#

CSS/动画#

CSS3 你用得比较多的有哪些？渐变、旋转、缩放、动画这些你了解吗？
做动画时，CSS 和 JS 分别怎么做？有什么区别？
Canvas 有没有用过？做过什么场景？
红包/福袋动画是怎么做的？打开的动作是画出来的，还是直接展示 UI 图？
动画有没有做过打开、抖动、浮动、阴影、缩放这类效果？

WebSocket#

前端连接流程是什么？怎么监听消息？怎么和后端约定事件？
有没有做心跳/保活？断开后怎么重连？
有没有遇到连接不上的情况？连接不上时怎么兜底？
是否会降级成 HTTP 轮询？轮询频率怎么控制？有没有用指数退避？
弱网情况下怎么提示用户？实时数据不准确时，前端怎么做交互提示？

ES6#

有哪些常用特性？什么是柯里化函数？
ES5 和 ES6 构造函数分别怎么写？
ES6 用什么构造对象？ES5 用什么构造对象？
Promise、扩展运算符、箭头函数、模板字符串这些是否了解？

浏览器兼容#

有做过浏览器兼容吗？需要注意哪些？CSS 兼容怎么处理？JS 兼容怎么处理？
低版本浏览器下，打包降级有没有遇到问题？
低版本浏览器里路由变了但页面不跳转，可能是什么原因？浏览器 API 不支持时怎么处理？
框架 Vue/React 是否已经帮你抹平了一部分兼容性？

Vue#

React 用得多，还是 Vue 用得多？
Vue 2 和 Vue 3 的区别是什么？
Vue 2 响应式原理是什么？Vue 3 响应式原理是什么？
Object.defineProperty 和 Proxy 有什么区别？
Vue 3 在性能上做了哪些优化？
Vue 2 里数组/对象变更为什么可能不触发视图更新？如果数据变了，但是视图没变，可能是什么原因？

PY 公司#

如何推动 AI 系统落地的？
用户问题如何路由到 AI 系统？意图识别是如何实现的？使用了哪些模型？
如何处理未登录用户的问题查询？
如何做向量化和知识库检索？文档、PDF、课件是如何切分、入库、人工审核的？
AI 输出如何保证序列化/结构化？为什么选择 Markdown 而不是 JSON？
数据库和后端架构是什么？
有没有做过微服务、数据中台或复杂后端系统？
花了多久落地？在落地过程中，你之前没有经验时是怎么学习的？
假设设计一个秒杀系统，你会怎么设计架构？高并发下如何避免超卖？
MySQL 本身怎么实现库存扣减？Redis 分布式锁或 Lua 脚本如何使用？
限流、接口削峰、事务和乐观锁如何落地？
如果不用 Redis，只用 MySQL，要怎么保证安全？
微信支付接入流程怎么设计？如何保证用户支付后积分/虚拟产品到账？
支付为什么要使用异步队列？如果队列挂掉，如何保证支付结果和系统状态一致？
回调验签具体流程是什么？
MCP、SKILL 或其他工具如何辅助开发？
产品经理缺失情况下，你们是如何自己出可交互草图和 PRD？

HQ 公司#

你日常使用 NextJS 多吗？
你使用 TypeORM，有没有了解过 Prisma？调研时对比过优缺点吗？
技术选型一般由谁来决定？
NestJS 的依赖注入中，Provider 默认是单例，还是每次请求新建实例？讲讲单例模式的优点？
如何给几十上百个接口统一增加操作日志/接口监控？
说说 Nest 管道（Pipe）的概念、作用和使用场景？
TypeORM 有哪两种运行模式？查询缓慢时，如何抓取它生成的 SQL 做调优？
有没有使用过 PostgreSQL？了解 PG 物化视图吗？
日常做过哪些 MySQL 慢查询、索引、SQL 优化？有没有分库分表、读写分离、数据库深度调优的实战经验？
使用 Bull Queue 处理视频解析、Embedding 长任务，进程崩溃/K8S 重启后，任务会不会丢失？
如何保证消息队列任务不丢失、保证任务一致性？
任务重试会造成重复执行、重复调用大模型，你项目中如何做重复推理优化、降低成本？
任务中途中断，如何实现断点续跑？前端如何感知后端任务中断、终止、运行状态？
讲讲 SSE 和 WebSocket 的区别，以及各自适用场景？
AGUI 协议动态渲染表单/卡片的整体实现流程？后端流式推送协议数据，前端如何实现边接收边流式渲染？
了解该协议底层 API 设计逻辑吗？
什么是数据库事务？结合你的项目，举例说明必须使用事务的业务场景？
LangChain 不同版本/模块的区别？多智能体中动态路由如何根据条件分配任务分支？
什么是查询改写？作用是什么？
你们知识库使用什么向量库？Elasticsearch + 向量库怎么做混合检索？整体流程？
混合检索已经做过分组、排序、去重，为什么还需要再次精排（Re-rank）？
项目中有使用领域词典吗？
Vue2 响应式原理，数组方法是如何重写拦截的？Vue2 中哪些数组方法无法被原生拦截？如何处理？
Vue3 Proxy 相比 Vue2 的优势？Vue3 中的 WeakMap/弱引用作用是什么？
解释下 Harness 相关概念？

YU 公司#

你求职过程中，最看重工作的哪些方面？过往工作中，主要承担开发还是管理角色？
日常使用哪些 AI 开发工具？通过什么渠道使用、费用及账号稳定性如何？
工作中遇到过哪些棘手难题，如何解决？
原公司技术部门、运维团队人员规模与架构是怎样的？
从前端转型全栈，你是如何学习并胜任后端工作的？
使用 AI 开发时，如何减少代码出错、降低重复劳动？
借助 AI 开发后，你的工作效率在团队中处于什么水平？
项目临近交付、出现前期未评估的风险问题，你会如何处理？
你对未来职业规划如何，偏向纯技术还是技术+管理路线？
公司前端、后端、算法及 AI 相关技术栈你是否了解？
仅口头需求、无完整页面设计时，如何借助 AI 输出页面原型与 UI/UX 方案？
业务方对原型提出新增功能、修改需求，你如何落地处理？
业务方要求输出多版设计方案，你的执行思路是什么？
针对当前 AI 生成的页面样式，从专业角度看存在哪些问题、该如何优化？
重点介绍你过往和 AI、RAG 相关的核心项目与工作内容。
项目中知识库的数据源来自哪里？
向量检索使用了哪些工具、模型，如何实现、效果怎样、如何优化？
项目中是否自主设计过智能体？具体实现方式是什么？
产品面向哪些用户，整体功能架构是怎样的？
你认为自身最擅长的工作环节是什么？除前端外还有哪些优势？
后端相关工作接触深度如何？你在 UI/UX 设计方面的经验如何？结合 AI 落地怎么做？

以上是实打实被拷打的问题，通过录音让 AI 整理的，欢迎各位佬一起交流或者分享下你们的面经～

数据： 2.6k 浏览量，497 赞，81 用户回复

归藏技能（Guizang Social Card Skill）小红书卡片制作流程

Thu, 11 Jun 2026 00:00:00 GMT

归藏技能（Guizang Social Card Skill）小红书卡片制作流程#

概述#

使用 guizang-social-card-skill（已安装于 /workspace/.omnibot/skills/guizang-social-card-skill/）为文章生成小红书 3:4 图文卡片（1080×1440px）。本流程记录以”OpenClaw工作原理解析.md”为素材的完整制作经验。

前置条件#

技能已安装：skills_list | grep guizang 确认存在
系统已装中文字体：wqy-zenhei（文泉驿正黑），位于 /usr/share/fonts/wqy-zenhei/
Chromium 浏览器：/usr/bin/chromium-browser
Node.js + Puppeteer 用于渲染输出 PNG

完整工作流#

Step 1：读取技能参考文件#

Terminal window

1
# 技能 SKILL.md 位于
2
/workspace/.omnibot/skills/guizang-social-card-skill/SKILL.md
3

4
# 关键参考文件
5
references/style-system.md       # 风格系统（Swiss / Editorial 两种模式）
6
references/layout-recipes.md     # 布局食谱
7
references/theme-presets.md      # 主题色板（Ink Classic / IKB Blue 等）
8
references/components.md         # 组件规范（字体、间距、圆角等）
9
references/platform-specs.md     # 平台规格（小红书 1080×1440, 3:4）
10
references/production-workflow.md # 生产工作流
11
assets/template-swiss-card.html   # Swiss 风格 HTML 模板
12
assets/template-editorial-card.html # 杂志风格 HTML 模板

Step 2：规划卡片内容与风格#

小红书规格：1080×1440px（3:4），导出 PNG

推荐风格：

Swiss International：科技、工程、AI 类文章（IKB Blue 强调色 #002FA7）
Editorial Magazine x E-ink：文艺、人文、生活类文章
手绘可爱风（Doodle）：需要自定义 CSS，参考本指南的”手绘风改造”部分

Step 3：配置素材图片#

三种方案：

A. 用户自行提供截图/照片（推荐最自然）
B. 从 Pexels/Unsplash 找免费素材图
C. AI 生成插画

B 方案操作（以 Pexels 为例）：

Terminal window

1
# 1. 在 Pexels 搜索科技/AI 相关图片
2
# 2. 打开图片详情页，通过 find_elements 找到下载链接
3
# 3. 用 wget 下载到 assets/ 目录
4
cd /workspace/social-card-openclaw/assets
5
wget -O robot-hand-blue.jpg "https://images.pexels.com/photos/8386437/pexels-photo-8386437.jpeg?cs=srgb&dl=pexels-tara-winstead-8386437.jpg&fm=jpg"

⚠️ 注意：Pexels 的图片 ID 随机，具体 URL 需从页面元素中提取。

Step 4：编写 HTML 卡片#

项目目录结构#

1
social-card-<slug>/
2
├── index.html       # 所有卡片帧的 HTML
3
├── render.cjs       # Puppeteer 渲染脚本
4
├── assets/          # 素材图片
5
└── output/          # 输出 PNG

HTML 结构要点#

每个卡片帧为一个 <section> 或 <div>，用 id 区分
设置 width: 1080px; height: 1440px; 匹配小红书规格
文字和关键内容保持在安全区内（上下左右留 60-90px 边距）
字体优先使用系统 WenQuanYi Zen Hei，避免 Google Fonts 加载失败

字体配置#

1
@font-face {
2
  font-family: 'WQ';
3
  src: local('WenQuanYi Zen Hei'), local('文泉驿正黑');
4
}
5
body {
6
  font-family: 'WQ', 'Noto Sans SC', sans-serif;
7
}

⚠️ 务必使用 @font-face 引用本地中文字体，防止 Chromium 脱机渲染时无法加载 Google Fonts 导致乱码或空白。

Step 5：渲染为 PNG#

方式 A：Puppeteer（推荐）#

安装依赖：

Terminal window

1
cd social-card-<slug>/
2
npm init -y
3
npm install puppeteer

渲染脚本 render.cjs：

1
const puppeteer = require('puppeteer');
2
const path = require('path');
3

4
(async () => {
5
  const browser = await puppeteer.launch({
6
    headless: 'new',
7
    executablePath: '/usr/bin/chromium-browser',
8
    args: ['--no-sandbox', '--disable-gpu', '--disable-software-rasterizer'],
9
  });
10
  const page = await browser.newPage();
11
  await page.setViewport({ width: 1080, height: 1440 });
12

13
  // 关键：添加 cache-busting 参数避免 Chromium 缓存旧文件
14
  const ts = Date.now();
15
  await page.goto('file://' + path.resolve(__dirname, 'index.html') + '?_=' + ts, {
16
    waitUntil: 'networkidle0', timeout: 30000
17
  });
18
  await page.evaluate(() => document.fonts.ready);
19
  await new Promise(r => setTimeout(r, 3000)); // 等字体和图片加载完成
20

21
  // 截取整个视口或特定元素
22
  await page.screenshot({ path: 'output.png', type: 'png' });
23

24
  // 或截取特定元素
25
  const el = await page.$('.frame');
26
  if (el) await el.screenshot({ path: 'output/result.png', type: 'png' });
27

28
  await browser.close();
29
})();

Show moreShow less

运行：

Terminal window

1
node render.cjs

方式 B：Chromium 命令行截图#

Terminal window

1
chromium-browser --headless --no-sandbox --disable-gpu \
2
  --screenshot=output.png --window-size=1080,1440 \
3
  "file://$(pwd)/index.html?_=$(date +%s)"

⚠️ 此方式在 Alpine proot 环境中偶有截图内容为空的 bug，优先使用 Puppeteer。

Step 6：预览与迭代#

用 file_read 预览生成的 PNG：

1
file_read("path/to/output.png")

手绘可爱风格实现（Doodle Style）#

风格特征#

暖色调纸纹背景（#fcf6eb / #faf3e8）
SVG 手绘装饰元素：云朵、星星、爱心、波浪线
拟人手绘感边框（虚线、波纹线）
柔和 pastel 配色：粉色 #ffb5c2、蓝色 #b5d8f7、黄色 #f9d56e
圆角、松散的手绘图标（纯 SVG 绘制）
无科技感图片，用 SVG 可爱插画代替

手绘装饰 SVG 示例#

1
<!-- 云朵 -->
2
<path d="M28 62 Q10 50 16 33 Q10 16 28 14 Q32 -2 56 4 Q72 -4 90 8 Q108 0 116 20 Q128 26 120 45 Q126 56 108 62 Q88 68 66 58 Q44 68 28 62Z" fill="#f0e0c8" stroke="#d4c4a8" stroke-width="2.5"/>
3

4
<!-- 星星 -->
5
<path d="M16 2 L19 12 L30 12 L21 19 L24 30 L16 23 L8 30 L11 19 L2 12 L13 12Z" fill="#f9d56e" stroke="#e8b84a" stroke-width="2"/>
6

7
<!-- 手绘分割线 -->
8
<path d="M10 13 Q40 6 70 12 Q100 18 130 10 Q160 4 190 14 Q220 22 250 9 Q280 2 295 14 Q310 18 320 12" stroke="#e0b896" stroke-width="3" fill="none" stroke-linecap="round"/>

手机阅读字体大小经验值（1080px 画幅）#

元素	字号	说明
主标题	76-84px	加粗，控制 1-2 行
标签/小标题	26-30px	点缀性文字
步骤标题	36-40px	流程图的每一步
步骤描述	30-34px	正文说明文字，行高 1.5
底部备注	24-26px	装饰性文字

流程卡片布局#

使用垂直时间线布局：

1
[步骤1图标] 步骤1标题
2
             步骤1描述文字
3
     |  (手绘竖线连接)
4
[步骤2图标] 步骤2标题
5
             步骤2描述文字
6
     |
7
[步骤3图标] 步骤3标题
8
             步骤3描述文字

每个步骤由 item 容器实现：

icn（固定宽度 76-90px，SVG 图标）
tx（弹性宽度，tit + desc）
竖线用绝对定位 step-line 或伪元素

常见问题 & 解决方案#

1. 修改 HTML 后渲染图片无变化#

原因：Chromium 会缓存 file:// URL 的内容，即使文件已更新。

解决方案：在 URL 后添加随机查询参数（cache-busting）：

1
const ts = Date.now();
2
await page.goto('file://.../index.html?_=' + ts, ...);

或使用全新的文件名/目录路径，彻底避免缓存。

2. 汉字渲染为方块或乱码#

原因：系统缺少中文字体，或 Google Fonts 在离线环境无法加载。

解决方案：

使用本地字体：@font-face { src: local('WenQuanYi Zen Hei'), local('文泉驿正黑'); }
不要依赖 @import url(https://fonts.googleapis.com/...) 加载中文字体
验证字体可用：fc-list :lang=zh

3. Chromium 截图内容空白#

可能原因：

--screenshot 参数与文件路径配合问题
字体加载超时

解决方案：改用 Puppeteer + waitForSelector + document.fonts.ready 确保完整加载。

4. Puppeteer 找不到 Chromium#

Terminal window

1
# 指定系统预装的 Chromium
2
executablePath: '/usr/bin/chromium-browser'

技术栈速查#

工具	用途	路径
guizang-social-card-skill	卡片设计规范与模板	`/workspace/.omnibot/skills/guizang-social-card-skill/`
Chromium	无头渲染引擎	`/usr/bin/chromium-browser`
Puppeteer	Node.js 截图控制	`node_modules/puppeteer`
WenQuanYi	中文字体	`/usr/share/fonts/wqy-zenihi/wqy-zenhei.ttc`
Node.js	运行渲染脚本	`/usr/bin/node` (v22)
Python HTTP server	本地调试用（可选）	`python3 -m http.server`

本次实践产出#

最终卡片：/workspace/cute-card/output.png（1080×1440 可爱手绘风）
HTML 源码：/workspace/cute-card/index.html
渲染脚本：/workspace/cute-card/render.cjs
文章原文：/workspace/小万工作间/工程现场/实战.经验/OpenClaw工作原理解析.md

小红书笔记提取操作指南

Thu, 11 Jun 2026 00:00:00 GMT

小红书笔记提取操作指南#

从小红书链接到结构化文档的完整工作流

概述#

从一个小红书(sharing)笔记链接开始，经过 链接解析 → 笔记数据获取 → 图片下载 → OCR 文字识别 → 清洗整理，最终得到可编辑、格式清晰的 Markdown 文档。

适用场景：图文笔记（carousel）、普通文字笔记、含多张图片的长文笔记。

流程图解#

1
小红书短链接 (xhslink.com)
2
       │
3
       ▼
4
  浏览器/API 解析为完整URL
5
       │
6
       ▼
7
  获取笔记元数据（标题、标签、图片列表、描述）
8
       │
9
       ├──纯文字笔记 → 直接提取文字
10
       │
11
       └──图文/图片笔记
12
              │
13
              ▼
14
          下载全部图片（19张以内）
15
              │
16
              ▼
17
          OCR 识别（中文简体）
18
              │
19
              ▼
20
          清洗整理 → 保存 Markdown

Show moreShow less

前置条件#

Alpine 环境中需要安装的工具：

方式 A：xhs CLI（推荐，适合快速读取）#

Terminal window

1
uv tool install xiaohongshu-cli

配置文件路径：~/.xiaohongshu-cli/cookies.json

需要三个 cookies：a1、webId、web_session。其中 web_session 通过调用 login_activate() API 自动获取（HttpOnly cookie，无法手动提取）。

1
# 获取 web_session 的示例
2
from xhs_cli.client import XhsClient
3
client = XhsClient(cookies)
4
client.login_activate()  # 自动获取并保存 web_session

常用命令：

Terminal window

1
xhs read <笔记URL>      # 读取笔记（支持完整URL）
2
xhs search <关键词>      # 按关键词搜索
3
xhs hot                  # 热门笔记
4
xhs feed                 # 推荐流

方式 B：XHS-Downloader（适合下载图片和批量操作）#

GitHub：JoeanAmier/XHS-Downloader v2.8

已安装在 /workspace/xhs-downloader，venv 使用 uv sync 创建。

Terminal window

1
# 启动API服务
2
cd /workspace/xhs-downloader
3
python main.py api --port 5556
4

5
# 调用API获取笔记详情
6
curl -X POST http://localhost:5556/xhs/detail \
7
  -H "Content-Type: application/json" \
8
  -d '{"url":"<完整URL>","download":false}'
9

10
# 返回数据包含 title、desc、image_list（含所有图片URL）

⚠️ 注意：不要用 uv run（会重编 nuitka，极慢），直接用 venv Python 路径。 venv Python 路径示例：/root/.cache/omnibot/uv-project-envs/.../bin/python

OCR 工具：Tesseract#

Terminal window

1
apk add tesseract-ocr tesseract-ocr-data-chi_sim

验证安装：

Terminal window

1
tesseract --list-langs
2
# 输出应包含：chi_sim

标准操作流程#

Step 1：获取完整笔记 URL#

小红书分享链接是 xhslink.com 短链，需要先解析。

方式一：用浏览器 navigate 解析

1
# 通过 browser_use 工具的 navigate action
2
browser_use(action="navigate", url="http://xhslink.com/o/xxxxxx")
3
# 结果中 currentUrl 即为完整的笔记 URL

方式二：用 xhs CLI 直接读取

Terminal window

1
xhs read "http://xhslink.com/o/xxxxxx"
2
# 如果提示 "No xsec_token — using HTML fallback"
3
# 需要先解析出完整URL再重试

完整 URL 格式示例：

1
https://www.xiaohongshu.com/discovery/item/{note_id}?xsec_token={token}&source=app_share

Step 2：获取笔记数据#

使用 xhs CLI 读取完整笔记数据：

Terminal window

1
xhs read "https://www.xiaohongshu.com/discovery/item/xxx?..."

返回的 YAML 格式数据包含：

字段	说明
`data.items[].note_card.title`	笔记标题
`data.items[].note_card.desc`	描述文本（含标签）
`data.items[].note_card.type`	笔记类型（normal=图文，video=视频）
`data.items[].note_card.image_list`	图片列表（含 url_default、width、height）

关键操作：从 image_list 中提取所有 url_default 字段，得到图片下载链接。

Step 3：下载所有图片#

编写 Python 脚本下载图片：

1
import urllib.request, os
2

3
urls = [...]  # 从 Step 2 提取的图片URL列表
4
img_dir = "/workspace/笔记名称_图片目录"
5
os.makedirs(img_dir, exist_ok=True)
6

7
for i, url in enumerate(urls):
8
    fname = f"{img_dir}/page_{i+1:02d}.webp"
9
    urllib.request.urlretrieve(url, fname)

注意事项：

图片格式为 .webp，可直接用于 OCR
图片数量通常 1-19 张
注意请求频率，可加 time.sleep(0.5) 避免被限

Step 4：OCR 识别#

对所有图片执行 Tesseract OCR：

Terminal window

1
cd /workspace/笔记目录
2
for f in page_*.webp; do
3
    echo "===== $f ====="
4
    tesseract "$f" stdout -l chi_sim 2>/dev/null
5
    echo ""
6
done

输出会按图片顺序展示识别文字。

Step 5：文字清洗与整理#

OCR 输出存在常见问题需要清洗：

常见OCR噪声#

噪声类型	示例	修正方法
中文间多余空格	”尝试用”	正则去除汉字间空格
符号混淆	”一” 误为 ”-“	替换为正确符号
英文拼写错误	”LLMI” → “LLM”	上下文精确替换
标点符号错乱	”`”、”·“	替换为标准标点
换行位置错误	行末多余换行	按语义合并段落

清洗 Python 示例#

1
import re
2

3
def clean_ocr_text(text):
4
    # 去除中文之间的空格
5
    text = re.sub(r'([\u4e00-\u9fff])\s+([\u4e00-\u9fff])', r'\1\2', text)
6
    # 修正中文标点前的空格
7
    text = re.sub(r'([\u4e00-\u9fff])\s+([，。；：？、！\)\])])', r'\1\2', text)
8
    # 特定错误修正
9
    text = text.replace("LLMI", "LLM").replace("—", "—")
10
    return text.strip()

Step 6：组织为结构化文档#

按照原文的段落层次组织：

1
# 笔记标题
2
> 来源：小红书笔记 | OCR提取于 YYYY-MM-DD
3

4
---
5

6
## 一级标题
7

8
正文内容...
9

10
### 二级标题
11

12
列表、表格、代码块...

文档结构建议：

保留原文的信息层级
使用 Markdown 表格替代原文中的对比/分类内容
代码目录结构用树形文本
重要结论或原则用引用或加粗突出

常见问题与处理#

1. xhs CLI 报 “Could not parse INITIAL_STATE from HTML”#

原因： 短链接(xhslink.com)未解析，或 xsec_token 缺失。

解决：

先用浏览器 navigate 短链接，获取重定向后的完整 URL
用完整 URL 重新执行 xhs read

2. xhs CLI 提示 “No xsec_token”#

原因： 缺少必要的安全参数。

解决： 需要完整 URL（含 xsec_token），而不是短链接。

3. Tesseract OCR 识别质量差#

原因及对策：

图片分辨率太低 → 使用原图 URL（非缩略图）
中文识别率低 → 确保 -l chi_sim 参数正确
背景复杂干扰 → 避免保存干扰较大的缩略图版本

4. 图片下载失败#

原因： 网络问题或 CDN 限流。

解决：

加 time.sleep(1) 降低请求频率
尝试切换为 url_pre 或 url_default 中的其他域名

完整执行示例#

以下是从链接到文档的完整终端命令序列：

Terminal windowShow moreShow less

1
# 1. 解析URL并获取笔记数据
2
xhs read "https://www.xiaohongshu.com/..." > /tmp/note_data.yaml
3

4
# 2. 提取图片URL并下载
5
python3 << 'EOF'
6
# 从YAML输出中提取 url_default 字段
7
# 下载到 /workspace/笔记名称_img/
8
EOF
9

10
# 3. OCR识别
11
cd /workspace/笔记名称_img
12
for f in page_*.webp; do
13
    tesseract "$f" stdout -l chi_sim >> /tmp/ocr_output.txt
14
done
15

16
# 4. 清洗整理为Markdown
17
python3 << 'EOF'
18
# 读取OCR输出，清洗，组织为结构化文档
19
EOF

Show moreShow less

目录规范#

笔记最终文档：/workspace/小万工作间/笔记标题_全文.md
图片临时缓存：可放在 /workspace/笔记简称/，完成清理后可删除
OCR 原始输出：不需要保留，只保留清洗后的版本

参考资料#

已安装 xhs CLI（uv tool install xiaohongshu-cli）
XHS-Downloader：/workspace/xhs-downloader（GitHub: JoeanAmier/XHS-Downloader v2.8）
Tesseract 文档：https://github.com/tesseract-ocr/tesseract
本指南关联 Skill：rednote-skill

Codex日常开发工作流

Wed, 10 Jun 2026 00:00:00 GMT

Codex 日常开发工作流#

背景#

来源：实习经验分享
时间：2026-06-05

工作流概览#

每天到办公室的标准化流程：

1. 环境准备#

打开电脑
启动 4 个 Codex 实例：
- 1 个 VSCode 插件
- 1 个 Desktop 客户端
- 2 个终端（终端 A、终端 B）

2. 需求对齐与规划（Desktop）#

在 Desktop 中对齐需求
进行任务拆解和规划
充分讨论后，让 Codex 生成一套 prompt

3. 执行阶段（终端 A）#

使用终端 A 开 plan 模式执行
Codex 的 plan 几乎直接执行，有时甚至不看、不拒绝

4. 代码审查（终端 B + VSCode 插件）#

终端 B：使用 /review 命令进行 review
VSCode 插件：使用针对此次任务的定制 prompt 来 review，追踪代码

5. 交付#

审查通过后直接 push，创建 PR

核心原则#

代码从不手写 — 所有代码都由 Codex 生成
所有问题都问 Codex — 碰到的任何问题，无一例外
充分讨论后再执行 — 规划阶段花足够时间，执行阶段高效推进

工作流图示#

1
Desktop (需求对齐/规划)
2
    ↓ 生成 prompt
3
终端 A (plan 模式执行)
4
    ↓ 代码产出
5
终端 B (/review) + VSCode 插件 (定制 review)
6
    ↓ 审查通过
7
git push → PR

关键思考#

这样会有提升吗？

这套流程的本质是把 人的角色从”写代码”转变为”审代码”，核心价值在于：

规划阶段充分思考，减少返工
多维度 review（终端 + 插件交叉验证）
所有问题都问 Codex，持续积累 prompt 经验

OpenClaw 工作原理解析：从消息输入到完整反馈

Wed, 10 Jun 2026 00:00:00 GMT

OpenClaw 的架构，以及它处理智能体执行、工具调用、浏览器操作等功能的实现逻辑，其中诸多设计思路对 AI 工程师极具借鉴价值。深入了解 Clawd 的底层运行机制，能让我们更清晰地认识这套系统的功能边界，更重要的是，明确它的优势与短板。

Clawd 的技术本质#

大家都知道，OpenClaw 是一款个人智能助手，可本地部署或通过大模型 API 调用，甚至在手机上就能轻松操作，但它的技术本质究竟是什么？OpenClaw 的核心是一个基于 TypeScript 开发的命令行应用（CLI），既非 Python 开发、也非基于 Next.js 的网页应用。作为一个独立运行进程，它的核心功能包括：

在本地设备运行并启动网关服务器，处理全渠道连接（电报、WhatsApp、斯拉克等）；
调用大语言模型 API（Anthropic、OpenAI、本地模型等）；
本地执行各类工具指令；
实现用户对电脑的各类操作需求。

技术框架#

为了更通俗地解释其架构，我们以”向 Clawd 发送消息到获取反馈”的完整流程为例说明。

OpenClaw 从发送消息到完整反馈的彩色手绘流程图

（流程链路：用户消息 → 通道适配器 → 网关服务器 → 会话路由器 → 智能体运行器 → 模型解析器 → 系统提示词构建器 → 历史加载器 → 会话 → 任务通道队列 → 上下文窗口防护机制 → 大语言模型 API → 智能体循环 → 反馈通路 → 通道适配器 → 最终文本）

在即时通讯工具中向 Clawd 发送指令后，会依次触发以下环节：

1. 通道适配器#

通道适配器接收用户消息并进行预处理，包括消息标准化、提取附件等。不同的即时通讯工具和输入流，都配有专属的适配器。

2. 网关服务器#

作为任务与会话的协调中枢，网关服务器接收用户消息并将其分发至对应会话，是 Clawd 的核心模块，可处理多个并行的请求。

Clawd 为了防止 AI 在处理多任务时把数据搞乱（竞态条件），放弃了那种看似高级但容易出错的”多线程异步”写法，而是采用了最稳妥的”排队叫号（命令队列）“机制。默认所有任务都乖乖排队（串行），只有明确安全的任务才允许插队同时做（显式并行），从而保证了系统极高的稳定性和可靠性。

那么，OpenClaw 怎么保证配置了一个 Agent，当有很多用户同时向他发送消息、让他处理任务的时候，怎么保证这个任务能够稳定执行呢？

我们可以把 OpenClaw 想象成一家 “只有一个超级大脑（Agent），但拥有完美管理系统的超级咨询公司”。当一大群客户（多个用户）同时涌进来提需求时，为了保证这个超级大脑不崩溃、不串台、稳定输出，Clawd 设计了 五道防线。

第一道防线：大堂经理精准分流（网关服务器）#

当很多消息同时涌来时，第一步绝不能让所有消息直接砸到 Agent 脸上。

机制：网关服务器就像银行的”大堂经理”。它接收所有消息后，会根据来源（比如 Telegram、WhatsApp）和发送者，把消息精准分发到对应的 “会话（Session）” 中。
作用：确保张三的消息进了张三的档案袋，李四的消息进了李四的档案袋，物理隔离，绝不混淆。

第二道防线：VIP 专属排队窗口（任务通道与命令队列）#

（这里就用到了咱们上一问聊过的核心概念！）

机制：网关分发后，每一个独立的会话，都会分配一个专属的”任务通道”。
比喻：就像银行给每个客户分配了专属的 VIP 柜台。
- 张三在 1 号窗口，他的 5 个任务在 1 号窗口乖乖排队（串行执行）。
- 李四在 2 号窗口，他的任务在 2 号窗口排队。
为什么能保稳定？ 因为 Agent 在 1 号窗口处理张三的任务时，绝对不会受到 2 号窗口李四任务的干扰。这就彻底消灭了前面提到的”竞态条件”（比如张三的任务和李四的任务同时去修改同一个文件导致崩溃）。各干各的，互不干扰，系统自然就稳了。

第三道防线：大脑的”防过载与急救”机制（智能体运行器）#

就算任务分开了，Agent 的”大脑（大模型 API）“和”记忆力（上下文窗口）“也是有限度的。Clawd 做了极其聪明的兜底设计：

API 自动切换（备用大脑）：如果当前使用的大模型 API（比如 Claude）突然宕机、限流或者密钥失效，智能体运行器会自动把这个密钥”关小黑屋（冷却）“，并瞬间切换到备用模型或备用密钥。用户根本感觉不到中间出了故障。
上下文压缩（防脑爆）：如果用户一直聊，对话记录太长，快把大模型的”上下文窗口（短期记忆容量）“撑爆了怎么办？系统不会直接崩溃，而是触发 “上下文防护机制”——让大模型把前面的长对话总结压缩成一段摘要，腾出空间继续工作；如果实在压缩不了，就”优雅降级”（体面地停止执行），而不是直接报错死机。

第四道防线：防死循环的”安全绳”（智能体循环限制）#

机制：Agent 在执行任务时，经常需要调用工具（比如读文件、执行代码、上网搜索），这被称为”智能体循环”。Clawd 给这个循环设置了一个最大次数限制（默认约 20 次）。
为什么能保稳定？ 假设 Agent 遇到了一个极其复杂的任务，或者因为理解错误陷入了”死循环”（比如一直在反复读取同一个报错文件）。如果没有安全绳，这个任务就会永远卡在那里，耗尽服务器资源。有了 20 次的限制，一旦达到上限，系统会强制掐断，防止单个任务拖垮整个系统。

第五道防线：影分身之术（子智能体机制）#

机制：如果某个用户的任务实在太庞大，主 Agent 还可以”生”出一个子智能体。
比喻：主 Agent 相当于项目经理，他把大任务拆分，派给子智能体（独立会话）去后台慢慢干。主 Agent 自己则腾出手来，继续接待其他新客户，或者通过”轮询”去查看子智能体的进度。这大大提高了系统的吞吐能力。

3. 智能体运行器#

这是真正承载 AI 能力的模块。该模块会确定待调用的模型、匹配对应的 API 密钥（若密钥失效，会将该配置标记为冷却状态并尝试下一个），若主模型调用失败，会自动切换至备用模型。

智能体运行器会结合可用工具、技能、记忆内容动态生成系统提示词，再加入会话历史（存储于 .jsonl 文件），随后将完整提示词传入上下文窗口防护机制，校验是否有足够的上下文空间。若上下文空间即将耗尽，系统会选择压缩会话内容（对上下文进行总结）或优雅降级终止执行。

4. 大语言模型 API 调用#

大模型调用环节会以流式方式返回结果，同时对不同服务商的 API 做了一层抽象封装；若所调用的模型支持深度思考功能，该模块还会触发模型的扩展思考逻辑。

5. 智能体循环#

若大模型返回工具调用指令，Clawd 会在本地执行该指令，并将执行结果补充至对话中。这一过程会反复执行，直至大模型返回最终文本结果，或达到最大循环次数（默认约 20 次）。正是在这一环节，Clawd 实现了其核心能力——电脑操作功能。

6. 反馈通路#

这一环节的逻辑较为常规：执行结果会通过原消息通道反馈给用户，同时会话数据会以基础的 jsonl 格式持久化存储，文件中每行都是一个 json 对象，记录了用户消息、工具调用指令、执行结果、模型反馈等内容，这也是 Clawd 的记忆实现方式——基于会话的记忆机制。

以上就是 Clawd 的基础架构，接下来我们聊聊其中几个关键的核心模块。

Clawd 的记忆机制#

没有完善的记忆系统，AI 助手的能力便会大打折扣。Clawd 通过两套系统实现记忆功能：

以 jsonl 格式存储的会话记录；
存储为 Markdown 格式的记忆文件，文件位于 MEMORY.md 或 memory/ 文件夹中。

在检索环节，Clawd 采用了向量检索与关键词匹配相结合的混合检索方式，兼具两种方式的优势。例如检索”认证漏洞（authentication bug）“时，系统既能找到提及”认证问题（auth issues）“的文档（语义匹配），也能精准定位包含该精确短语的内容（关键词匹配）。

其中，向量检索基于 SQLite 实现，关键词检索则借助 SQLite 的扩展模块 FTS5 完成，嵌入向量生成服务商支持自定义配置。这些 Markdown 记忆文件由智能体通过常规的”写入”文件工具生成，无专属的记忆写入 API，智能体只需向 memory/*.md 路径写入内容即可。

当新的对话开始时，系统会提取上一轮的对话内容，并将其总结为 Markdown 格式的文件。

Clawd 的记忆系统设计出乎意料地简洁，无需合并记忆文件，也无需按每月/每周的周期压缩记忆内容。这种简洁性是优势还是缺陷，因人而异，但我始终推崇可解释的简洁设计，而非混乱复杂的架构。

Clawd 的记忆会永久保存，且新老记忆的权重基本一致，不存在记忆衰减曲线。

Clawd 的核心能力：电脑操作实现#

这是 Clawd 的核心壁垒之一：可接管本地电脑并实现各类操作。其实现逻辑与大家的直观认知基本一致。

Clawd 会向智能体开放较高权限的电脑操作能力，相关风险由用户自行承担。它通过执行工具（exec tool）在设备上运行 Shell 命令，支持三种运行环境：

沙箱环境（默认）：命令在 Docker 容器中运行；
本地宿主机；
远程设备。

除此之外，Clawd 还配备了各类工具：

文件系统工具（支持读取、写入、编辑）；
基于 Playwright 实现的浏览器工具，可生成语义快照；
进程管理工具，用于执行后台长期运行的命令、终止进程等。

安全机制（或近乎缺失？）#

与 Claude Code 类似，Clawd 为用户设置了命令白名单，用户可对各类命令进行权限审批，支持三种操作：单次允许、始终允许、拒绝，并会向用户弹出审批提示。Clawd 的安全机制与 Claude Code 的设计思路高度相似，核心是在用户允许的范围内，给予智能体最大的自主操作权限。

浏览器工具：语义快照而非截图#

Clawd 的浏览器工具并非主要依赖截图，而是采用语义快照——一种基于页面无障碍树（ARIA）的文本化表示形式。

所以 Agent 将看到：

1
- textbox "Email" [ref=2]
2
- textbox "Password" [ref=3]
3
- link "Forgot password?" [ref=4]
4
- heading "Welcome back"
5
- list
6
  - listitem "Dashboard"
7
  - listitem "Settings"

这透露了四个显著优势。正如你可能已经猜到的，浏览网站并不一定是视觉上的任务。截图大小为 5 MB，语义快照则少于 50 KB，且仅占图像代币成本的一小部分。

动态系统提示词#

与大多数框架不同，Clawd 的系统提示词并非固定不变，而是结合技能、记忆检索结果、用户身份、时区等信息动态构建。其基础系统提示词如下：

1
## 工具集
2
可用工具（按策略筛选）：工具名称区分大小写，需严格按列出的名称调用。
3
- read：读取文件内容
4
- exec：运行 Shell 命令
5
- browser：控制网页浏览器
6
[...仅显示该智能体可访问的工具]
7

8
## 工具调用风格
9
默认规则：常规、低风险的工具调用无需说明（直接调用即可）；
10
仅在以下场景需补充说明：多步骤操作、复杂问题、敏感操作。
11

12
## 子智能体/智能体生成
13
智能体可以生成子智能体（但子智能体无法再生成下一级智能体）。
14
子智能体拥有独立会话，父子智能体通过 session_send 实现通信，
15
子智能体的执行结果会反馈给父智能体，
16
父智能体可通过轮询子智能体会话查看执行进度。

Show moreShow less

上下文压缩#

当接近上下文长度限制时，智能体会将关键信息保存至记忆中。会话历史会被拆分为多个片段，由大语言模型对片段进行总结，最终合并为连贯的摘要，替换原始消息内容。

个人AI工具使用盘点

Wed, 10 Jun 2026 00:00:00 GMT

linuxdo 最新AI资讯获取，在这里看其他人分享的开源项目，AI使用经验，踩坑记录等 ominibot手机端智能体，处理word,excel，获取各个网站信息保存为文档整理个人资料库 obsidian md阅读器，整理阅读信息 codex,claude code cli搭配grillme,superpower技能实现规范高效率开发

01 Agent评测四层体系

Wed, 10 Jun 2026 00:00:00 GMT

Agent 评测四层体系#

第一层：保底#

确保系统每次改动后仍能稳定运行，否则无法判断是否“改坏”。

第二层：固定题目 benchmark#

使用通过率、耗时和失败原因评估效果，而非凭感觉判断。

第三层：过程记录#

记录运行过程以便复盘，避免只看到最终结果。

第四层：线上反例回归#

将真实翻车的 case 放回评测集，使评测体系更贴近真实场景且更具说服力。

面试价值#

该体系回答了三个问题：

指标来源：说明指标可量化，并非主观编写。
优化验证：证明优化过程可工程化验证，而非玄学。
系统扩展性：表明 Agent 评测是持续演进的闭环，而非一次性脚本。

实践建议#

在 Agent 项目中补充评测体系，展示可复现、可审计、可扩展的评测机制。这些上线时需考虑的实际细节往往更能打动面试官。

内容来源：用户提供的校招项目经验分享，已客观整理。

02 0417字节Agent开发一面问题及参考回答

Wed, 10 Jun 2026 00:00:00 GMT

0417字节Agent开发一面问题及参考回答#

3. 有没有观察过同一个模型在不同 context 长度下的表现差异？#

参考回答： #精华观察到随着 context 增长，模型对早期信息的记忆和关联能力显著下降，容易出现重复操作或偏离初始目标。因此需要在代码中设计合理的上下文压缩和摘要机制，优先保留关键约束和历史决策依据。

6. 讲一下你项目里面用户在终端发一条指令后，系统是怎么处理的？#

参考回答： #精华用户输入指令后，系统首先会进行解析和上下文组装，然后调用 LLM 进行规划，生成工具调用序列。每一步工具执行的结果都会反馈给模型，模型根据结果决定是否继续调用工具或输出最终答案。整个过程会被记录下来，用于后续的复盘和优化。

7. 怎么减少这个链路里面Agent的幻觉？#

参考回答： #精华一是通过精细设计工具的 schema 和 description，让模型清楚知道能做什么、不能做什么；二是在上下文中显式注入关键约束和历史信息，减少模型“猜”的概率；三是引入验证环节，对模型输出的代码或操作进行静态检查或执行测试。

8. Prompt是怎么构建的？#

参考回答： Prompt 是模块化的，分为系统提示、用户指令、上下文片段、工具描述等部分。我会根据任务类型动态调整 Prompt 内容，比如长任务会加入更多历史摘要，复杂任务会加入 Few-shot 示例。所有 Prompt 的修改都会记录在案，便于复盘。

17. 平常怎么学习新知识的？#

参考回答：主要通过阅读官方文档、复现开源项目、参与技术社区讨论、以及在实际项目中踩坑来学习。遇到问题时，会先查资料，再动手实验，最后总结成笔记或分享给他人，形成闭环。

我的回答： #精华乐于下载使用体验github热门的项目如openclaw 了解现在比较流行的ai coding工具如claude code codex opencode 。加入了waytoagi，datawhale这些AI相关社区参与一些课程学习讨论。我倾向于先实践边做边学，因为等学完所有知识准备好，可能已经比别人落后很多了。遇到问题我会通过CSDN，linux do等专业网站以及谷歌搜索，询问chatgpt等寻找解决方案

1. 为什么要自己搞一个code agent？这个过程中你觉得哪部分是比较有挑战的？#

参考回答：

为什么要做code agent：
- 第一是可控性：Claude Code 这类产品对用户是黑盒（如 prompt 拼装、上下文组装、工具调用条件），难以判断正确或错误的原因。自己搭建可以把关键环节摊开看清楚。
- 第二是隐私和部署要求：实验室项目有保密约束，不适合放在外部闭源服务。项目预留了接开源模型的能力（如实验室部署的 Qwen），保证在保密场景下也能实际使用。
有挑战的部分：
1. 上下文工程：长仓库任务中，模型在未超窗时利用长历史的质量会下降，出现偏离初始 spec、误用旧信息、重复操作等问题。
2. 工具设计：tool description 和 schema 的小改动会显著影响完成率，工具粒度、装载方式的设计都需要仔细考虑。

2. 那你自己用的code agent，用过哪些？体验如何？#

参考回答：主要使用过 Claude Code 和 Cursor。Claude Code 在复杂任务上表现较好，但黑盒严重；Cursor 在代码补全和局部修改上很顺手，但全局规划能力稍弱。自己开发主要是为了弥补两者的不足，实现完全可控和可定制。

4. Claude code源码泄漏了你有关注吗？有什么看法？#

参考回答：关注到了。这提醒我们在使用闭源服务时要警惕“供应商锁定”和潜在的安全风险。这也进一步验证了自己开发可控 agent 的价值——数据和逻辑都在自己掌控范围内，避免敏感信息泄露风险。

5. Harness在你这个项目里面怎么体现的？#

参考回答：在我的项目里，harness 主要体现在评测体系上。设计了一套四层评测机制，通过固定 benchmark、记录运行过程、回放真实翻车 case 等方式，确保每次改动都能被量化评估，而不是靠感觉。

9. 讲一下你的code agent的memory机制是怎么做的？#

参考回答： memory 机制分为短期和长期。短期 memory 是当前对话的上下文窗口，长期 memory 是将历史任务的关键信息（如代码结构、已完成步骤、用户偏好）进行向量化存储和检索，在需要时动态注入到上下文中。

10. 任务恢复是什么意思，怎么做的？#

参考回答：任务恢复是指当 Agent 在执行过程中中断（如报错、超时、用户暂停）后，能够从上次状态继续执行。做法是记录每一步的执行状态和上下文快照，中断后读取快照，重新初始化 Agent 状态并继续执行。

11. 突然问了目前项目支不支持使用s…（可能是ssh或selenium等工具）#

参考回答：支持。比如如果需要远程操作服务器，会封装一个 ssh 工具；如果需要自动化测试网页，会封装 selenium 工具。工具的接入都需要定义清晰的 schema 和权限控制。

12. 现在你这个pico里面有什么工具？#

参考回答：（pico 可能指项目代号或容器环境）目前集成了代码编辑器、文件读写、命令行执行、Git 操作、浏览器自动化、API 调用等工具，基本覆盖了日常开发的主要场景。

13. 详细问了下怎么做的评测，怎么验证优化效果？#

参考回答：设计了一套四层评测机制：第一层保底，确保系统稳定跑；第二层用固定题目做 benchmark，通过率、耗时、失败原因量化效果；第三层记录运行过程，方便复盘；第四层把线上真实翻车 case 放回评测集。优化后通过对比 benchmark 的通过率和耗时变化来验证效果，确保不是“玄学优化”。

14. 有没有用过claude code的 /btw 功能？#

参考回答：用过。/btw 是 Claude Code 的一个快捷指令，用于快速生成代码修改建议。这个功能很实用，但在项目里更倾向于通过结构化 Prompt 和工具调用来实现类似功能，更可控、更可复用。

15. 整个项目中ai coding的占比，会…（可能是“会占多少时间”或“会如何变化”）#

参考回答： AI coding 在项目初期占比很高，主要用于搭建框架和生成样板代码；中后期占比下降，更多用于代码审查、重构建议和复杂逻辑生成。总体来说，AI 是辅助工具，人的决策和架构设计仍是核心。

16. 你觉得一个好的code agent应该具备哪些特质？#

参考回答：我认为一个好的 code agent 应该具备：① 可控性强，关键环节透明；② 工具丰富且设计合理；③ 上下文管理高效，能处理长任务；④ 具备自我验证和恢复能力；⑤ 评测体系完善，能持续迭代优化。

03 小厂AI应用开发一面问题及参考回答

Wed, 10 Jun 2026 00:00:00 GMT

小厂AI应用开发一面问题及参考回答#

4. 讲下skill的运作机制，skill的内容是以什么形式返回给大模型的？#

参考回答：

运作机制：当用户提问或触发条件满足时，系统会从 skill 库中匹配最合适的 skill，然后将其内容注入到当前的 Prompt 上下文中，交由大模型处理。
返回形式：通常是以自然语言描述 + 结构化参数（JSON Schema）的形式。例如，先有一段描述该 skill 功能的说明文字，再附带一个定义好输入输出格式的 JSON Schema，让模型知道如何调用。

5. 上下文压缩的时机和方法？#

参考回答：

时机：当检测到当前上下文长度接近模型上限（如 80% 阈值），或在多轮对话中历史信息开始冗余、对当前任务贡献度下降时触发。
方法：
- 摘要压缩：用模型对历史对话或长文本生成摘要，保留核心信息。
- 关键信息提取：抽取实体、动作、意图等关键要素，丢弃次要描述。
- 滑动窗口：只保留最近的 N 轮对话，丢弃较早的上下文。

6. #精华进行完这个agent优化后有什么可量化的效果？#

参考回答：

准确率提升：如任务完成率从 70% 提升到 85%。
响应速度加快：平均响应时间从 5s 降低到 3s。
Token 成本下降：通过上下文压缩和缓存，单次请求平均 Token 消耗减少 30%。
用户满意度提升：如 NPS 评分或人工评估得分提高。

1. skill沉淀怎么处理的？#

参考回答：

通常会将业务方或开发者编写的 skill 沉淀到结构化存储中（如数据库、向量数据库或配置文件）。
沉淀时会包含 skill 的元数据（如名称、描述、触发条件）、核心逻辑（如 Prompt 模板、工具调用 Schema）以及版本信息，以便后续检索、复用和迭代。

2. 对拉取的skill做了缓存，是为了处理什么情况？是怎么考虑何时更新缓存的？#

参考回答：

目的：主要是为了提升性能，减少每次请求时重复加载 skill 的延迟；同时降低后端存储或外部服务的压力。
更新策略：通常采用 TTL（Time To Live）+ 主动失效机制。例如，设置缓存过期时间（如1小时），或者在 skill 被编辑/更新时，通过消息队列或钩子函数主动清除对应缓存，确保下次拉取的是最新版本。

3. 如果业务方有人写了过长的skill会导致什么问题？#

参考回答：

上下文溢出：过长的 skill 容易撑爆大模型的上下文窗口，导致关键指令被截断，模型理解偏差。
性能下降：Prompt 过长会增加模型推理时间，提高 Token 消耗成本。
噪音干扰：冗余内容可能干扰模型注意力，降低任务执行的准确性和稳定性。

7. 怎么处理内置和业务自定义skill的冲突问题？#

参考回答：

命名空间隔离：内置 skill 和业务 skill 使用不同的命名前缀或目录结构，避免同名冲突。
优先级机制：定义明确的优先级规则（如内置 skill 优先级高于业务 skill，或反之），在匹配时按优先级选择。
冲突检测告警：在 skill 注册或更新时，自动检测是否存在同名或功能重叠的 skill，提示人工审核。

8. 为什么要使用multi-agent架构？#

参考回答：

职责分离：不同 agent 专注不同任务（如查询、分析、执行），代码结构更清晰，易于维护。
能力扩展：可独立扩展某个子 agent 的能力（如增加工具、优化 Prompt），不影响整体系统。
协作效率：主 agent 负责任务分解和调度，子 agent 并行或串行执行，提升复杂任务的完成效率。

9. 主agent与子agent如何通信？能否访问对方的memory？#

参考回答：

通信方式：通常通过消息队列（如 Redis、RabbitMQ）或 HTTP/RPC 接口进行异步或同步通信。主 agent 将任务指令发送给子 agent，子 agent 完成后返回结果。
Memory 访问：一般不直接访问对方的 memory。每个 agent 的 memory 是其内部状态（如对话历史、中间结果），通过通信传递所需数据，保持模块解耦。如需共享状态，可通过共享存储（如数据库）或上下文对象传递。

10. 这个DAG工作流有没有使用什么已有的AI框架还是自己实现的？#

参考回答：

选择自己实现，因为现有框架（如 LangChain、AutoGen）虽然封装完善，但往往存在过度抽象、黑盒化、扩展性差、性能损耗等问题。自己实现可以更精细地控制每个节点的执行逻辑、错误处理和状态管理，更好地贴合业务需求，也便于后续优化和调试。

AI Coding环节：实现一个todo辅助agent#

参考思路：

功能：添加任务、删除任务、标记完成、查看列表、设置提醒。
技术点：使用 Python + Flask/FastAPI 提供 API，或命令行交互；用 SQLite/JSON 存储任务；可接入大模型实现自然语言解析（如“提醒我明天开会” → 解析为任务+时间）。
代码结构：主类 TodoAgent，包含 add_task、remove_task、list_tasks、complete_task 等方法，支持命令行或 HTTP 调用。

反问：进去以后的业务内容方向#

参考回答（作为候选人提问）：

“请问团队目前在 AI Agent 应用方面主要聚焦哪些业务场景？是偏向内部提效工具，还是面向外部用户的商业化产品？”
“未来半年内，团队在 Agent 架构、多模态能力或工程化落地方面有哪些重点规划？我可以提前做哪些准备？”

注：以上回答基于行业常见实践整理，实际面试中请根据个人项目经验调整。

04 分享一些有效的AI Agent项目面试话术

Wed, 10 Jun 2026 00:00:00 GMT

分享一些有效的AI Agent项目面试话术#

问题背景#

大家面试是不是也有这样的经历：明明自己亲手做过项目，但是面试过程中越说越虚，张口就说”我做了RAG、重排序、状态管理”，术语都没错，但面试官只会觉得你只看过方案，根本不像落地做过项目。

想让Agent的项目听起来百分百是自己实操落地，核心不是背更多技术名词，而是用有过程、有细节、有思考的表达还原真实项目逻辑。

四个核心优化步骤#

一、先讲业务场景，不说技术名词#

错误开场：千万不要开口就说我做了一套多Agent的系统。

正确做法：先讲清楚你解决的真实问题，明确项目面向的业务场景、用户痛点、核心目标，后面所有技术选型才有落地意义。

示例话术：

我做的是XX场景的智能应用，核心解决用户复杂问题无法单次处理、人工操作繁琐低效的痛点。通过任务拆解、实时检索、工具自动执行，降低人工成本，提升任务处理效率。

二、少讲最终用了什么，多讲方案的迭代过程#

错误做法：只说”我们用了多Agent架构”——完全没有说服力。

正确做法：真正做过的人一定会讲方案从零到一的迭代逻辑：最初的方案是什么、为什么要推翻、遇到了什么问题才改成最终版本。

示例话术：

我最开始用单Agent完成规划+执行的全流程，最后发现任务链路一旦拉长，任意环节出错就会导致整个任务失败，且问题极难定位排查。因此后续拆分出规划、执行分别优化提示词、管控工具调用，大幅提升系统的稳定性与可维护性。

三、不说空泛优化，讲具体改动与效果#

错误做法：“我做了RAG优化，加了重排序，提升效果”——这是空话。

正确做法：必须讲明白原来的方案存在的问题、修改了什么、优化后的结果。

示例话术：

最初那个模块直接将召回的文本全部塞入上下文，召回条数过多时，模型就极易被无关的噪声干扰，生成内容质量下降。后续我新增重排序模块，将召回的Top 10调整为Top 5，优先保留高相关度的内容，有效过滤噪声，让模型输出更精准稳定。

四、抛弃抽象术语，多用落地动作描述#

错误做法：“做了状态管理、做了容错处理、做了工程优化”——抽象表达听起来专业，实则毫无实感。

正确做法：把抽象名词换成你亲手做了什么具体动作、解决的实际问题，真实感瞬间拉满。

示例话术：

因为Agent要处理多步连贯任务，中间产生的结果后续环节需要复用，所以我单独设计了任务状态持久化存储。单个工具调用超时或者异常时，可以从断点恢复执行，不需要从头重启整个任务链路，减少重复消耗，提升任务成功率。

万能面试表达公式#

可以直接套用的四步表达逻辑：

先讲业务痛点与目标
再讲初版方案与落地问题
接着讲踩过的坑与迭代改动
最后讲优化效果与价值

核心原则：项目从来不怕复杂度低，最怕没有细节、没有迭代、没有独立思考。把这套逻辑讲清楚，面试官会直接认定你是真正落地过项目的人选。

常用术语对照#

语音转录原文	实际术语	说明
a站 / a镇	Agent	智能体
多a点	多Agent	多智能体架构
rap	RAG	检索增强生成
Rick to	RAG	检索增强生成
长久处理	任务处理	-
出版方案	初版方案	-

本文档由视频语音转录整理，原始视频：分享一些有效的AI Agent项目面试话术

05 Agent项目大厂实习建议小红书笔记

Wed, 10 Jun 2026 00:00:00 GMT

Agent 项目冲大厂实习建议（摘自小红书笔记）#

来源：小红书「黄同学h」
链接：http://xhslink.com/o/9Nubmmnrl54
抓取时间：2026-05-31

🚫 简历上太多人做的”过时”项目（容易沉底）#

项目类型	问题所在
聊天助手	2024 年还行，现在已经不够看了
旅游 Agent	缺少包装且太多人做，毫无差异化
各种 RAG（BM25 + Reranking）	面试官都背熟了，毫无惊喜
LoRA 微调 / 爆改模型结构	面 Agent 岗却做算法方向，方向不对口

✅ 作者认为好的 Agent 项目应具备的要素#

展示技术 taste（审美）
—— 2026 年了，讲点类似 OpenClaw 或 Claude Code 的架构，面试官才会感兴趣
展示技术深度
—— 在 1-2 个模块深入展开，要有方案设计和 trade-off 分析
有差异度
—— 别人都是智能客服 / RAG，你掏出 Code Agent，面试就不无聊了
有合理场景设计
—— 支撑「业务场景 → 方案设计 → 收益」式的项目描写链路

🎯 作者推荐方向：轻量化 Code Agent#

贴合面试官日常使用场景，面试时有共同话题可聊
设计克制，不堆砌功能
附带完整代码、文档和配套笔记
据称已有同学通过该项目拿到 腾讯、字节、阿里、Pico 等实习

⚠️ 注：该笔记本质上是作者推广其付费项目的营销内容，但项目选题思路和简历包装方向有一定参考价值。

06 AI应用开发面试复盘老颂

Wed, 10 Jun 2026 00:00:00 GMT

AI 应用开发岗位面试复盘（摘自小红书笔记）#

来源：小红书「AI践行者-老颂」
标题：上午面了一个AI应用候选人，说实话有点可惜
抓取时间：2026-05-31

面试概况#

候选人简历写得很满：LangChain、RAG、微调、提示词工程、向量数据库、模型部署都有，但一问细节就露馅了。

暴露的四大短板#

1️⃣ RAG 基础不扎实#

面试追问	暴露问题
向量数据库是干什么的？	回答模糊
分块策略？为什么很多场景用固定大小滑动窗口？	卡住答不上
用户问专业问题，模型答非所问，第一步查什么？	思路混乱

真正做过的人会怎么答？

直接联想到 召回的上下文相关性、prompt 约束是否到位
会用 评估集跑一遍不同分块和召回策略的效果对比

2️⃣ 提示词工程停留在表面#

“做过 prompt 优化、提示词工程”
→ 一问 结构化 prompt 的设计原则，答不上来
→ 说明平时只是在 “改现成模板”，不是理解系统逻辑

3️⃣ 工程意识 / 可靠性设计不足#

需要思考的问题：

用户输入恶意指令或无关问题，模型乱输出怎么办？
上下文窗口溢出，系统怎么降级？

比较稳妥的方案（至少要说出来）：

1
输入校验 → 意图识别 → 敏感词过滤 → 上下文截断策略 → 错误兜底话术

关键设计原则：

先校验用户输入，再决定是否调用模型
对关键输出做 二次校验和格式解析，再返回给用户
不是为了”好看”，是为了系统不会因为一次异常请求直接崩掉

4️⃣ 性能优化只停留在表面#

很多人只会说 “用了流式输出”

真正做过的会继续讲：

优化维度	具体做法
缓存	调用前哪些步骤可以缓存
批处理	哪些请求可以批量处理
超时策略	模型推理超时怎么设置，重试还是降级
上下文管理	上下文太长时怎么做摘要，效果和成本之间怎么权衡

这些细节，才是工程能力。

🎯 面试准备建议（原文总结）#

把自己做过的一个项目重新拆一遍：

业务需求 — 怎么对齐
RAG 设计 — 怎么设计
Prompt — 怎么写
异常兜底 — 怎么兜
性能优化 — 怎么优化
数据处理 — 怎么处理

再把高频模块整理成 “四件套”：

原理 → 配置 → 常见问题 → 排查方法

💡 核心观点#

企业现在更看重的，不是你会不会调个 API，而是：

出了问题你能不能定位

系统异常你能不能兜住

方案落地后你能不能让它稳定跑起来

🏷️ 标签#

#AI大模型 #LLM应用开发 #面试技巧 #求职 #程序员转型 #RAG #技术干货

07 字节一面面经 JiexinX

Wed, 10 Jun 2026 00:00:00 GMT

字节一面面经（AI/后端方向）#

来源：小红书「Jiexin.X」
岗位方向：AI 应用 / 后端开发
抓取时间：2026-05-31

面试流程（22题全记录）#

项目 & 经历环节#

序号	问题	候选人回答 / 表现	反思
1	自我介绍	✅ 完成
2	项目是网上找的还是什么？	老实承认	❌ 不要纯诚实，可以包装一下项目来源
3	有实习过吗？	无	❌ 实习经历是重要加分项
4	项目中挑战最大的是什么？	答了微调，面试官说没听懂产出，解释后仍跳过	❌ 项目挑战要说清楚”问题→方案→收益”链路
5	出现幻觉怎么处理？	提示词 → 工具 → RAG → 微调	✅ 架构意识有，但深度不够
6	提示词具体怎么做？	要基于真实内容回答，不知道就说不知道	⚠️ 太基础
7	还有其他提示词吗？	想不到了	❌ 缺少结构化 prompt 储备
8	Agent 短期/长期记忆怎么实现？	答得不好	❌ 高频考点，必须准备
9	设计一个 Agent 要考虑哪些模块？	答得一坨（太开放）	❌ 需要准备系统架构图式的回答
10	API 超时和报错怎么解决？	根据重要程度处理	⚠️ 太笼统
11	有没有考虑用大模型自己排查 API 超时和报错？	说了 SKILL	✅ 但可深入
12	消耗 token 过快怎么排查？	说了 SKILL 和压缩	✅ 但不够系统

Java / 计算机基础环节#

序号	问题	候选人回答	反思
13	讲一下 Java 线程池	✅ 吟唱八股
14	重新设计一个线程池会怎么设计？	答得一坨（牛客刷到过但没在意）	❌ 八股要理解原理，能举一反三
15	怎么把 class 文件加载到 JVM 中？	答得一坨	❌ 类加载机制基础题
16	MySQL 的 undolog、redolog、binlog 区别和场景？	✅ 开始吟唱
17	什么是两阶段提交？	✅ 吟唱八股
18	多线程写一个死锁	太久没写，没写出来（面试官换题）	❌ 多线程基础薄弱
19	随便写一个单例模式	双检查锁 ✅
20	为什么要加 volatile 关键字？	✅ 吟唱八股

算法环节#

序号	问题	表现	反思
21	合并两个有序数组	一秒写完 → 面试官问是不是刷过 → 老实承认	✅ 会做；❌ 下次假装思考一下

反问环节#

| 22 | 反问 | 正常结束 |

💡 面试者自评#

刚开始问那几个问题就感觉凉了，感觉面试官更想要有实习经历或者有突出项目的人，对我项目不太感兴趣。
面试官还是挺耐心和善的，后面可能看我答得不好就问了几个简单的八股。

🎯 从这份面经可以吸取的教训#

项目准备方面#

项目来源要会包装 — 不要直接说”网上找的”
项目挑战要有完整叙事 — 问题 → 方案设计 → 量化收益
Agent 相关的高频深度题必须准备：
- 短期/长期记忆实现方案
- Agent 架构设计（至少从规划→工具→记忆→执行→反馈闭环说清楚）
- 幻觉处理层级（提示词约束 → 工具/函数调用 → RAG 召回 → 微调对齐）
- API 超时、报错、token 消耗的排查和优化策略（缓存、批处理、上下文压缩、降级）
- 结构化提示词设计原则

八股基础方面#

不能只会背”是什么” — 面试官会追问”你怎么设计一个 X”（如线程池、Agent架构）
多线程基础不能丢 — 死锁、锁、并发编程是高频考点
JVM 类加载机制 — 经典必问题
MySQL 日志体系 — undo log、redo log、binlog + 两阶段提交，属于必考八股组合
刷过的算法题，面试时假装思考一下再写

🏷️ 标签#

#字节跳动 #一面面经 #AI应用开发 #后端开发 #Java #面试复盘 #实习

08 阿里淘天AI应用开发一面有只小粉

Wed, 10 Jun 2026 00:00:00 GMT

阿里淘天 AI 应用开发一面面经（5.27）#

来源：小红书「有只小粉」
岗位：AI 应用开发
面试时长：1 小时 30 分钟
抓取时间：2026-05-31

面试流程#

项目深挖环节（Agent 项目逐层追问）#

这份面经最精彩的部分——面试官对 Agent 项目扣得非常细，几乎覆盖了从设计到落地全链路：

序号	面试问题	考察点
1	自我介绍	基础表达
2	详细介绍 Agent 项目的细节和难点	项目真实性 + 技术深度
3	会话压缩怎么做的？	上下文管理核心技术
4	长期记忆写入的时机？	记忆系统设计
5	上下文结构怎么组织的？有没有进行长度约束？	Prompt 工程 + Token 控制
6	`agent.md` 和 `memory.md` 的职责区分是什么？	Agent 系统架构理解
7	如果把工具和 skill 的位置交换一下，会产生什么后果？	系统设计 + 架构权衡
8	`skills.md` 的结构内容？skills 怎么导入？	Skill 机制实现
9	记忆检索怎么做的？怎么生成长期记忆，prompt 怎么组织的？	记忆系统全链路
10	怎么进行评测？Agent 回答的评测怎么做？	质量保障 + 评估体系

⚠️ 这些问题说明面试官也在做类似的 Agent 系统，问得非常专深，需要真正做过 Agent 项目才能答好。

研究生课题环节#

序号	问题
11	聊了一下研究生的课题内容
12	课题当中有什么挑战
13	有没有遇到具体的问题，和解决方案

C++ 基础环节#

序号	问题
14	STL 的什么结构可以做 KV？
15	哈希表底层的实现？冲突了怎么处理？
16	如果有一个并发场景，怎么去保证读写的线程安全？

以上三个问题总共 1 小时（含项目深挖）

AI Coding 环节#

序号	环节说明
17	目标人群提取的引擎 — 面试官让在写代码前先进行思考，然后根据与 AI 交互去完善和优化思路

这是一个新颖的 Coding 模式：不是直接让手写代码，而是先设计方案思路，再和 AI 协作迭代优化。

💡 面经核心洞察#

Agent 项目的 7 个必准备深水区#

结合这份面经和之前的字节面经，Agent 项目高频追问集中在：

会话压缩 — 怎么压缩、什么时机触发、摘要策略
长期记忆 — 写入时机、生成 prompt、怎么检索
上下文结构 — 系统提示词怎么组织、长度约束策略
配置/职责划分 — agent.md、memory.md、skills.md 各负责什么
Skill 机制 — 结构、导入、与工具的职责区分
评测体系 — Agent 回答质量怎么评估
架构权衡 — 互换组件（如工具⇄skill）会有什么后果

值得注意的点#

面试官对 Agent 项目极度了解，大概率也在做类似系统
要把项目每个模块的”为什么这么设计”想清楚，不止是”怎么做的”
AI Coding 环节的新趋势：不要求一上来就手撕代码，而是考察思考和协作能力
时长 1.5h，说明面试官愿意深挖，也能扛住才是真功夫

🏷️ 标签#

#阿里 #淘天 #一面面经 #AI应用开发 #Agent #面经 #暑期实习

09 腾讯AI应用开发一面逸

Wed, 10 Jun 2026 00:00:00 GMT

腾讯 AI 应用开发一面#

来源：小红书笔记（作者：逸，2026-04-11）
链接：http://xhslink.com/o/2yiaDG9CXww
数据：3357 点赞 / 6245 收藏 / 120 评论 / 863 分享

1. 什么是 Agent？#

Agent（智能体）是一种能够感知环境、做出决策并采取行动的系统。核心组件包括：

Planning（规划）：任务分解与反思
Memory（记忆）：短期/长期记忆存储
Tools（工具）：调用外部 API、代码执行等
Action（执行）：实际执行操作

2. Agent 和普通 LLM 应用的区别？#

普通 LLM 应用：输入→输出，单轮对话
Agent：具备自主规划、使用工具、多步推理的能力，可以循环执行直到完成任务

3. 常见的 Agent 框架有哪些？#

LangChain：最流行的 Agent 框架，链式调用
LlamaIndex：专注 RAG 和数据索引
AutoGPT：全自动 Agent
MetaGPT：多 Agent 协作
CrewAI：角色扮演多 Agent

4. 什么是 RAG？#

RAG（Retrieval-Augmented Generation）检索增强生成：

将文档切分成 chunks
通过 embedding 模型转为向量
存入向量数据库
用户提问时，先检索相关文档
将检索结果 + 用户问题一起传给 LLM 生成答案

5. RAG 的关键步骤？#

文档解析与分块（Chunking）
向量化（Embedding）
检索（Retrieval）
增强生成（Generation）

6. 常见的 Embedding 模型？#

OpenAI text-embedding-3-small/large
BGE 系列（BAAI）
M3E
Cohere Embed

7. 常见的向量数据库？#

Milvus：开源，高性能
Pinecone：云原生
Weaviate：支持混合搜索
Chroma：轻量级
FAISS：Facebook 开源

8. 什么是 Prompt Engineering？#

通过设计和优化提示词来引导 LLM 生成期望的输出。常见技术：

Zero-shot / Few-shot
Chain-of-Thought (CoT)
ReAct
Self-consistency

9. LLM 的关键参数？#

Temperature：控制随机性（0=确定，1=随机）
Top-p：核采样概率阈值
Max tokens：最大输出长度
Frequency penalty：重复惩罚

10. 什么是 Function Calling / Tool Use？#

让 LLM 能够调用外部工具：

定义工具的 JSON Schema
LLM 决定是否调用、调用哪个工具、传什么参数
系统执行工具并返回结果
LLM 基于结果生成最终回答

11. Agent 中的记忆系统？#

短期记忆：当前对话上下文（Context Window）
长期记忆：持久化存储（向量数据库、文件系统）
工作记忆：任务执行过程中的中间状态

12. 什么是 Multi-Agent？#

多个 Agent 协作完成复杂任务：

角色分工（研究员、程序员、审核员等）
通信机制（消息传递、共享状态）
常见模式：顺序执行、并行执行、层级管理

13. Fine-tuning vs RAG？#

维度	Fine-tuning	RAG
成本	高（需要GPU训练）	低
更新	需要重新训练	实时更新
适用	特定风格/格式	知识问答
幻觉	可能加剧	有参考减少

14. 如何处理 LLM 幻觉？#

RAG 提供参考文档
设置 temperature=0
要求模型引用来源
后处理验证
使用 Self-consistency

15. 如何评估 LLM 应用？#

自动评估：BLEU、ROUGE、BERTScore
人工评估：准确性、相关性、流畅性
LLM-as-Judge：用 GPT-4 评分
RAG 评估：检索召回率、答案相关性

16. 部署 LLM 应用的考虑？#

延迟优化（流式输出、缓存）
成本控制（模型选择、token 限制）
可扩展性
安全性（输入过滤、输出审查）

17. AI 安全和对齐问题？#

RLHF（基于人类反馈的强化学习）
Constitutional AI
Red Teaming
内容过滤和安全护栏

18. 你有什么想问的？#

（面试反问环节建议）

提取自小红书笔记图片（共18页），2026-05-31 整理

10 滴滴AI全栈开发一面

Wed, 10 Jun 2026 00:00:00 GMT

滴滴 AI 全栈开发一面（不区分前后端）#

来源：小红书笔记
链接：http://xhslink.com/o/5d3Gt8uZdSq
标签：互联网大厂、agent、后端开发、大厂、程序员、面试求职、大模型、春招、校招、java

面试题目（共40题）#

基础与编程#

MCP是什么
手写单例
简单的coding题（忘了）
GraphQL RESTful区别
前后端分离
HTTP 1.0/2.0/3.0区别
JS闭包
异步请求：Promise async await
React生命周期
网络
缓存
算法
python和js的区别

AI Agent 与 MCP#

具体讲AI项目
mcp怎么运作的？
mcp有哪些协议，有什么区别？
mcp怎么处理并发调用？
你对AI coding tools的了解有多少？
国内的模型和国外的模型有什么差距？
做题：字符串相加
你怎么理解agent的？
mcp是什么？（重复）
mcp给你最大的感受是什么？
你认为mcp这种协议或者其他协议能解决什么问题？
AI工具在你做项目的时候能占比多少？
MCP与Skill的区别是什么？
ai在你日常编程中的运用？
ai编程的理解？如何把握自己的能力
ai编程的潜在问题
能简单介绍一下这段经历吗？
项目中ai的作用？
智能体有哪三个要素，分别有什么作用？
RAG了解吗
项目具体业务、拆分工具流程等
你还知道哪些工具协议，除了MCP?
两个机器人对话如何实现？
聊工作经历，大概问了一下是否使用过Vibe coding

Python 进阶#

python多进程，多线程，协程

Prompt 相关#

Prompt技巧

开放性问题#

项目提问

题目分类统计#

类别	数量
MCP/AI Agent	~15
前端基础	~6
后端基础	~4
编程题	~4
项目经验	~5
其他	~6

提取自小红书笔记文字描述，2026-05-31 整理

11 Agent八股记忆检索RAG

Wed, 10 Jun 2026 00:00:00 GMT

Agent八股分享：一天速通记忆/检索（RAG）#

来源：小红书笔记
链接：http://xhslink.com/o/8tkHC8Q3yVK
标签：互联网大厂、agent、java、后端开发、实习、暑期实习

1️⃣ 必问主线#

什么是 RAG？为什么它比直接让模型回答更适合企业知识问答？
RAG 和微调有什么区别？什么时候用哪个？
RAG 和长上下文模型谁更好？
为什么说 RAG 不是一个”向量库项目”？
一个 RAG 系统为什么会答错？
RAG 的核心指标有哪些？
什么时候不应该上 RAG？
为什么很多 RAG demo 看起来能跑，线上却不好用？

2️⃣ 检索链路与效果优化#

为什么说 chunking 决定了检索系统的上限？
chunk size 应该怎么定？
overlap 有什么作用，为什么不能太大？
embedding 模型怎么选？
为什么很多系统要加 rerank？
cross-encoder rerank 和向量召回的关系是什么？
为什么 dense retrieval 很强了，生产里还要 sparse？
Hybrid Retrieval 的本质是什么？
Query Rewrite 的目的是什么？
query rewrite 有什么风险？
Hybrid Retrieval 和 rerank 的关系是什么？
元数据为什么对检索效果重要？
late chunking 解决什么问题？
Contextual Retrieval 的核心思想是什么？

3️⃣ Memory 与 RAG 边界#

RAG 和 Memory 最本质的区别是什么？
为什么会话历史不等于长期记忆？
session state 和 memory 有什么区别？
缓存是不是一种记忆？
为什么说 memory 需要写入策略？

4️⃣ 长期记忆与用户记忆#

长期记忆和用户画像有什么区别？
为什么长期记忆不能每轮都写？
你会把哪些信息写成常驻记忆？

5️⃣ Agentic RAG / GraphRAG 进阶题#

什么是 Agentic RAG？
什么情况下普通 RAG 不够用？

提取自小红书笔记文字描述，2026-05-31 整理

12 AI面经 AI Agent四种范式对比

Wed, 10 Jun 2026 00:00:00 GMT

大家好欢迎来到本期技术面试深度解析聊一道面试题对比AI agent四种饭时react, plan, and execute multi agent以及to use agent各自是用什么场景如何做技术选行这道题大多数人的回答会查在列定意义上把四种饭时逐个解释一遍就结束但面试官要的是从工程维度理解本质差异和区设逻辑关注我五分钟吃头一道高平面试题深入拆解技术原理和面试官意图首先来看知道题的考察意图面试观问这道题背后考察两个关键能力第一是 agent 架构的工程感之力能不能从延迟可靠性可观测性等维度评价一个饭时第二是技术选行探断力面向具体场景能不能准确选出该用哪种饭时为什么那怎么拆解呢我们先从最常见的误区说起很多人默认以为这四种是现性进化关系 to use 最简单 react 高级一点 plan and execute 更高级 multi agent 最牛这是面试中最大的坑实际上他们根本不是同意维度的比较对象 to use 是基础能力层决定模型能不能调用外部工具 react 是推理框架层定义推理和行动怎么交替plan and execute 控制流程规定先规划还是边想边做 multi agent 是组织架构层关心多个 agent agent 怎么协作四层可以跌加而不是护持 outline 里的一个 agent 就可以同时用react 的 function calling 整体又是multi agent 架构清楚了层次关系回答才不会跑偏这就引出了关键认知选行不是四选一而是根据场景在每一层做组合决策那每一层怎么选呢先说 to use 这层模型根据上下文自主决定要不要掉工具掉哪个传什么参数拿到结果后继续回复优势是延迟低架构简单但面对多不推理是每一步独立决策缺少全局规划容易偏离目标所以它最适合单一或简单调有比如查天气发有见这类确定行操作当问题来了如果任务不只是调一两个工具这就引出了react 饭式核心是推理和行动交支进行格式是thought action observation 3段循环先思考下一步做什么执行动作拿到观察结果再继续思考最大价值是可解释性打开日质能看到每一步的决策链入代价是延迟每多一轮循环就多一次LLM要用适合中等复杂度且对可观测性要求高的人物比如客服工单数去分析但react 解决不了一个更深层的问题任务如果需要十几步光靠边向边做不仅慢而且容易迷失方向怎么办这就引出了plan and execute 饭式理念是先规划再执行模型在动手前深层完整计划然后逐步执行这解决了react缺乏全局视野的弱点代价是规划消耗推理资源计划可能不准确好的时间是在执行中引入重新规划机制适合步驟多弹结构清晰的任务比如大型代码重够复杂数据处理流水线但还有一个更几手的问题如果任务复杂度已经超过单个agent的能力边界了这就引出了multi agent 多智能体饭式思路是把复杂任务拆给多个专门 agent 每个有自己的角色工具和知识范围通过消息或共享状态协作最大好处是职责分离每个agent的上下文窗口只需关注自己的范围主流框架如Alton Gen和Cru A 通过编排着 agent 解决鞋桃问题适合角色编解清晰的鞋作场景比如软件工程的多角色配合内容编审发流程好自种饭式讲完了面试官很可能会追问一个深华问题技术选行的优先极怎么盘这里给一个使用框架低看任务复杂度单步或少量调用直接用towels多不推理家可解释新上react 步骤多且结构画高用pland and execute 只有角色天然分离或单agent 上下文窗不下时才上multiagent 第二看延迟敏感度实时交互优先towels或最简react 后台批处理充分发挥后两者优势第三看可观测性需求 react的循环是天然审计追踪

2026 05 07 阿里淘天 AI应用开发一面

Wed, 10 Jun 2026 00:00:00 GMT

阿里淘天 AI 应用开发面经（一面）#

时间：2026-05-07 来源：小红书笔记

1. 自我介绍#

个人教育背景及项目经验概述。

2. Java 基础与并发#

HashMap:
- 底层数据结构（数组+链表+红黑树）。
- 为什么链表长度为8时转红黑树？
- 扩容机制与线程安全问题。
线程池:
- 核心参数（corePoolSize, maximumPoolSize, keepAliveTime, workQueue, handler）。
- 工作原理与任务排队策略。
- 常见的拒绝策略。
并发编程:
- synchronized 实现原理。
- ReentrantLock 与 synchronized 的区别。
- CAS 与 AQS 简单介绍。

3. AI 应用开发相关#

RAG (Retrieval-Augmented Generation):
- 详述 RAG 的完整链路（Embedding -> Vector Store -> Retrieval -> Generation）。
- 如何通过 RAG 减少模型幻觉？
- 常用的向量数据库（如 Milvus, Pinecone）选型对比。
- 文档切片（Chunking）的策略对检索质量的影响。
Prompt 工程:
- 常用的提示词技巧：Few-shot（少样本学习）、CoT（思维链）。
- 如何优化 Prompt 以获得更稳定的输出。
AI Agent (智能体):
- 介绍 Agent 的核心组件：规划 (Planning)、记忆 (Memory)、工具使用 (Tool Use)。
- ReAct 框架的工作模式。
模型评估:
- 如何评估 AI 应用的效果？（RAGAS 框架、人工标注等）。

4. 系统设计与场景题#

高并发 AI 对话系统:
- 如何设计架构以支持大量并发请求？
- 消息队列在系统中的应用。
性能优化:
- LLM 推理延迟高，如何优化用户体验？（流式输出 SSE/WebSocket）。
- 缓存策略（Semantic Cache）的应用。

5. 反问环节#

团队的技术栈与具体的业务落地场景。
对面试表现的反馈。

Agent Super Result Handling 整理

Wed, 10 Jun 2026 00:00:00 GMT

Agent_Super_Result_Handling#

问题#

Agent_Super_Result_Handling

标准回答#

Agent 调用工具返回超大结果的处理与 OpenClaw 实践#

Agent 调用工具返回超大结果（如代码搜索返回 50KB 文本）会带来三个？接问题：

Token 爆炸：50KB 文本按 1 token≈4 字符估算，单条结果吃掉 12000+ token。
挤占上下文空间：128K 窗口下，一条结果占近 10%，挤压历史、System Prompt 和用户消息。
延迟飙升：处理大结果增加计算和传输成本。

处理思路分两步：限额 + 截断。为每条 tool result 设字符上限，超限则采用 head+tail 截断：保留开头让模型理解内容，保留尾部抓住错误信息，中间砍掉并加省略标记。

OpenClaw 实现两层防护： 单条截断：按 context window 的 30% 设上限（硬上限 400K 字符）。检测尾部是否包含错误关键词（error/exception/traceback 等），有则 head 占约 70%（最少 2000 字符）、tail 占 30%（上限 4000 字符）分割；否则只保留开头。截断后附加提示，告知内容不完整，可用 offset/limit 重新获取。 全局预算守卫：每次请求前计算总字符开销，超过 context window 的 75% 时，从最早的 tool result 开始替换为占位提示，优先牺牲早期结果，保证新内容空间。

扩展知识#

1. 为什么不能只保留前 N 个字符#

直接 substring(0, maxLen) 会丢失关键信息。例如 grep 搜索最相关匹配可能在中后部；命令执行失败时，真正的错误栈在末尾。
head+tail 策略虽不完美，但能兜住两头。OpenClaw 的 truncateToolResultMessage() 对多 block 内容按比例分配字符，避免单一 block 独占。
hasImportantTail() 动态检测尾部是否包含错误关键词或 JSON 闭合结构，只有命中才启用 head+tail，否则只保留开头。

2. 字符预算计算#

单条上限 ≈ context window tokens × 每 token 字符数 × 30%（代码文本 token 密度高，OpenClaw 对 tool result 用换算系数 2）。128K 模型：单条约 150K 字符。
全局预算 ≈ 128K × 4 × 75% ≈ 384K 字符。

3. 其他框架处理对比#

LangChain：ToolMessage 默认不截断，社区实践在 parser 层加限制。
Anthropic Claude：文档建议单条 tool result 不超过 100K 字符。
AutoGPT：早期无截断，context 常被撑爆，后加 max_length 参数。

面试官追问#

Q1：截断后模型基于不完整信息做错误判断，怎么处理？#

A：在截断标记中明确告知内容被截断，并建议使用 offset/limit 或请求特定部分重新获取。OpenClaw 截断后缀会说明“Content truncated”并提供重新获取指引。更优做法是附上原始内容的字符数和行数，让模型判断信息损失程度，必要时发起二次精确查询（如缩小范围、指定行号）。

Q2：head+tail 的比例怎么定？#

A：无通用最优比例，依赖 tool 类型：

搜索类工具（结果按相关性排序）：head 更重要，可 head 占 70%、tail 占 30%。
命令执行类工具（关键信息在末尾）：head 40%、tail 60%。

OpenClaw 实际使用 tail 占 30%（上限 4000 字符），head 拿剩余且最少保留 2000 字符。仅当 hasImportantTail() 检测到尾部有关键词时才走 head+tail，否则默认只保留开头。

Q3：除了截断，还有哪些方式处理超大 tool result？#

A： 工具端过滤：如代码搜索只返回最相关 top 10，不吐全量。 摘要模型压缩：用 sub-agent 先将大结果压缩成摘要再喂给主模型（如 Anthropic 内部实践）。分页：将大结果拆成多页，模型可选翻页获取更多内容。

截断是最简单的兜底方案，理想情况下应在工具端控制输出量。

关键点#

Agent 调用工具返回超大结果的处理与 OpenClaw 实践#

Agent 调用工具返回超大结果（如代码搜索返回 50KB 文本）会带来三个直接问题：

Token 爆炸：50KB 文本按 1 token≈4 字符估算，单条结果吃掉 12000+ token。
- 挤占上下文空间：128K 窗口下，一条结果占近 10%，挤压历史、System Prompt 和用户消息。
- 延迟飙升：处理大结果增加计算和传输成本。
处理思路分两步：限额 + 截断。
为每条 tool result 设字符上限，超限则采用 head+tail 截断：保留开头让模型理解内容，保留尾部抓住错误信息，中间砍掉并加省略标记。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Agent_Super_Result_Handling

Agent 调用工具返回超大结果（如代码搜索返回 50KB 文本）会带来三个直接问题：

Token 爆炸：50KB 文本按 1 token≈4 字符估算，单条结果吃掉 12000+ token。
- 挤占上下文空间：128K 窗口下，一条结果占近 10%，挤压历史、System Prompt 和用户消息。
- 延迟飙升：处理大结果增加计算和传输成本。
处理思路分两步：限额 + 截断。为每条 tool result 设字符上限，超限则采用 head+tail 截断：保留开头让模型理解内容，保留尾部抓住错误信息，中间砍掉并加省略标记。
OpenClaw 实现两层防护： 单条截断：按 context window 的 30% 设上限（硬上限 400K 字符）。检测尾部是否包含错误关键词（error/exception/traceback 等），有则 head 占约 70%（最少 2000 字符）、tail 占 30%（上限 4000 字符）分割；否则只保留开头。截断后附加提示，告知内容不完整，可用 offset/limit 重新获取。
本文已做格式统一与噪声清理，保留原始语义。
- Token 爆炸：50KB 文本按 1 token≈4 字符估算，单条结果吃掉 12000+ token。
- 挤占上下文空间：128K 窗口下，一条结果占近 10%，挤压历史、System Prompt 和用户消息。
- 延迟飙升：处理大结果增加计算和传输成本。
处理思路分两步：限额 + 截断。为每条 tool result 设字符上限，超限则采用 head+tail 截断：保留开头让模型理解内容，保留尾部抓住错误信息，中间砍掉并加省略标记。
OpenClaw 实现两层防护：
本文已做格式统一与噪声清理，保留原始语义。

Agent暑期实习面经

Wed, 10 Jun 2026 00:00:00 GMT

Agent暑期实习面经#

来源：小红书 @菌菌原文链接：http://xhslink.com/o/1bp55UaMqkL 发布时间：2026-04-27 标签：暑期实习、暑期实习面经、面经收藏 1095 · 点赞 699 · 评论 57

背景说明#

我从后端转 Agent，但是简历里没写任何后端内容，某种程度上缩减了面试官拷打的范围，因此大部分时间都在深挖项目，几乎没有任何传统后端八股。

以下是从数十场大厂暑期面试提炼而来的 Agent 面经。

Agent 方向#

你们这个 multi-agent 选型的依据
ReAct 范式你们怎么用的，其他的范式
LangGraph 介绍一下，有改进过哪些框架吗
记忆机制怎么做的
OpenClaw、Claude Code 看过吗
大模型的安全与薄弱点：prompt 工程、上下文工程、fallback 策略、retry 机制、reflection 机制、LLM 选型原因（工程侧非训练侧，每场面试问的方向不一样，但我都总结为实践经验）
意图识别怎么做的，指标如何衡量的（简历有写，每场必问）
multi-agent 系统评测、单 agent 本身评测

LLM 方向#

大模型幻觉
输入输出长度
RAG
调用 API

算法方向#

Transformer
注意力机制
位置编码
交叉熵损失函数
过拟合
梯度消失
数据并行
模型并行
生成式大模型
Transformer 流程

Agent 深挖（高频）#

幻觉
Function Calling
Prompt Engineering
Tool Use
ReAct
CoT（链式思维）
记忆管理
自我纠错
Planning
反馈机制
Multi-Agent
记忆存储、压缩、优化
模型评估
SSE 协议
A2A 协议
MCP 协议
RAG 优化
拆分任务机制
边界 case
循环调用
Token 优化
模型选择
Multi-Agent 通信

Agent超大结果面试题整理版

Wed, 10 Jun 2026 00:00:00 GMT

Agent 工具调用返回超大结果的处理策略#

面试题：Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？

一、超大结果带来的三个问题#

问题	说明
Token 爆炸	50KB 文本 ≈ 12000+ token，一条结果就干掉 128K 窗口的近 10%
挤占上下文空间	对话历史、系统提示、用户消息全被挤压，模型理解质量直线下降
延迟飙升	API 按 token 计费，多塞进去的大部分是噪声，等于花钱买垃圾

二、处理思路：限额 + 截断#

核心原则：给每条 tool result 设一个字符上限，超了就砍。

截断策略：head + tail 截断

保留开头：让模型知道内容是什么
保留尾部：抓住错误信息（错误堆栈、诊断信息往往在末尾）
中间砍掉 + 加省略标记

📌 类比：看日志时，最后几行的报错信息通常最关键。

三、OpenClaw 的两层防护#

第一层：单条截断#

参数	值
字符上限	context window 的 30%
硬上限	400K 字符
head 占比	约 70%（最少保留 2000 字符）
tail 占比	约 30%（上限 4000 字符）

智能检测：hasImportantTail() 检测尾部是否包含关键词（error/exception/failed/traceback 等）或 JSON 闭合结构，只有检测到才走 head+tail 分割，否则默认只保留开头。

截断后附加提示：告诉模型内容不完整，可以用 offset/limit 重新获取。

第二层：全局预算守卫#

每次发 LLM 请求前，通过 transformContext 管线自动执行全局预算检查：

先把每条 tool result 按单条上限裁一遍
估算所有消息的总字符开销
如果超过全局预算（context window 的 75%），从最早的 tool result 开始逐条替换为占位提示

📌 核心思路：越早的 tool result 对当前决策影响越小，优先牺牲给新内容让路。这是一种抢占式策略——不等 context overflow 报错，主动腾空间。

字符预算计算公式#

1
字符预算 = context window tokens × 每 token 字符数 × 比例系数

以 128K token 模型为例：

预算类型	计算	结果
单条上限	128000 × 0.3 × 4	≈ 150K 字符
全局预算	128000 × 4 × 0.75	≈ 384K 字符

⚠️ OpenClaw 对 tool result 用 token 换算系数 2（而非 4），因为代码和结构化文本的 token 密度比自然语言高，估算更保守准确。

四、扩展知识#

为什么不能只保留前 N 个字符？#

最简单的方案 result.substring(0, maxLen) 会丢关键信息：

grep 搜索返回 200 个匹配，最相关的那条可能在中间或末尾
命令执行失败，stdout 里一堆正常输出，真正的 error 在最后几行

📌 只保留开头 → 模型拿到的全是无用信息，还以为执行成功了。

head+tail 策略虽然不完美，但至少能兜住两头。

多 block 内容处理#

truncateToolResultMessage() 对多 block 内容会按比例分配字符 budget，每个 block 都能分到一份额度，避免某个 block 独占所有空间。

其他 Agent 框架怎么处理#

框架	处理方式
LangChain	ToolMessage 默认不截断，社区实践通常在 tool 的 output parser 层加限制
Anthropic Claude	建议单条 tool result 不超过 100K 字符
AutoGPT	早期版本没做截断，文件读取返回太大直接撑爆 context，后来才加了 `max_length` 参数

五、面试官追问#

Q1：截断后模型根据不完整信息做了错误判断，怎么处理？#

答：

在截断标记里告诉模型内容被截断了，让它自己决定要不要重新获取
附上原始内容的字符数和行数，模型就能判断丢了多少信息
如果模型觉得关键信息可能在被截断的部分，可以发起更精确的二次查询（缩小搜索范围或指定行号范围）

OpenClaw 的截断后缀会明确告诉模型 Content truncated，并建议使用 offset/limit 参数。

Q2：head+tail 截断的比例怎么定？#

答：没有通用最优比例，看 tool 的类型。

工具类型	推荐比例	原因
搜索类工具	head 70% / tail 30%	结果按相关性排序，head 更重要
命令执行类工具	head 40% / tail 60%	关键信息往往在末尾（错误堆栈）

OpenClaw 的做法：

tail 拿 budget 的 30%（上限 4000 字符）
head 拿剩余大部分空间（最少保留 2000 字符）
只有 hasImportantTail() 检测到尾部含 error/exception/traceback 等关键词时才走 head+tail，否则默认只保留开头

Q3：除了截断，还有没有其他方式处理超大 tool result？#

答：有三种思路：

方式	说明
工具端过滤	代码搜索只返回最相关的 top 10 结果，不吐全量
摘要压缩	用摘要模型先把大结果压缩成摘要再喂给主模型（Anthropic 内部有类似 sub-agent）
分页	把大结果拆成多页，模型可以选择翻页获取更多内容

📌 截断是最简单粗暴的兜底方案，理想情况下应该在工具端就控制好输出量。

六、总结思维导图#

1
Agent 工具返回超大结果怎么办？
2
├── 带来的问题
3
│   ├── Token 爆炸
4
│   ├── 挤占上下文空间
5
│   └── 延迟飙升
6
├── 处理思路：限额 + 截断
7
│   └── head + tail 截断（保留开头+尾部）
8
├── OpenClaw 两层防护
9
│   ├── 1. 单条截断（context window 30%，硬上限 400K）
10
│   └── 2. 全局预算守卫（context window 75%，抢占式压缩）
11
├── 关键设计
12
│   ├── hasImportantTail() 智能检测
13
│   ├── 多 block 按比例分配
14
│   └── 截断后附加提示（支持 offset/limit）
15
└── 其他方案
16
    ├── 工具端过滤（top N）
17
    ├── 摘要压缩（sub-agent）
18
    └── 分页

Show moreShow less

来源：面试鸭 · 2026最新AI大模型原理和应用面试题 整理时间：2026-05-29

AI Generate CRUD Code 现场实操整理

Wed, 10 Jun 2026 00:00:00 GMT

AI_Generate_CRUD_Code_现场实操#

问题#

AI_Generate_CRUD_Code_现场实操

标准回答#

现场实操：给定数据Schema生成符合RESTful规范的CRUD接口代码#

这是一道典型的现场实操题，考察候选人利用AI工具快速生成后端代码的能力？在15分钟内完成，需要遵循以下步骤：

操作流程： 理解Schema：提取数据模型定义（字段、类型、约束、关系） 设计RESTful端点：

GET /resources - 列表查询（支持分页、过滤、排序）
POST /resources - 创建资源
GET /resources/{id} - 获取单个资源
PUT /resources/{id} - 全量更新
PATCH /resources/{id} - 部分更新
DELETE /resources/{id} - 删除资源 生成代码：使用AI工具（如Copilot、ChatGPT）输出控制器、服务层、数据访问层代码 解释关键逻辑：验证、错误处理、状态码选择、数据一致性

关键实现逻辑要点：

数据验证：使用DTO + 校验注解（如@Valid、@NotNull、@Size）
错误处理：全局异常处理器返回标准错误格式（如{“code”: 400, “message”: “...”}）
RESTful状态码：
201 Created（POST成功）
200 OK（GET/PUT/PATCH成功）
204 No Content（DELETE成功）
404 Not Found（资源不存在）
分页规范：使用page、size参数，返回{“data”: [], “total”: 100, “page”: 1, “size”: 20}

扩展知识#

1. 常用框架示例（Spring Boot）#

1
// Controller示例
2
@RestController
3
@RequestMapping("/api/users")
4
public class UserController {
5
@GetMapping
6
public Page<UserDTO> list(@PageableDefault Pageable pageable) { ... }
7

8
@PostMapping
9
@ResponseStatus(HttpStatus.CREATED)
10
public UserDTO create(@Valid @RequestBody UserCreateDTO dto) { ... }
11

12
@GetMapping("/{id}")
13
public UserDTO get(@PathVariable Long id) { ... }
14

15
@PutMapping("/{id}")
16
public UserDTO update(@PathVariable Long id, @Valid @RequestBody UserUpdateDTO dto) { ... }
17

18
@DeleteMapping("/{id}")
19
@ResponseStatus(HttpStatus.NO_CONTENT)
20
public void delete(@PathVariable Long id) { ... }
21
}

Show moreShow less

2. 数据验证的错误响应#

使用@Valid触发校验，MethodArgumentNotValidException处理
返回格式：{“field”: “email”, “message”: “邮箱格式不正确”}

3. AI生成代码的技巧#

明确约束：在prompt中包含Schema定义、技术栈（如Spring Boot 3 + JPA）、代码风格要求
分步生成：先生成实体类，再生成Repository、Service、Controller
人工修正：检查生成的业务逻辑是否正确，补充遗漏的验证规则

面试官追问#

Q1：如果Schema包含嵌套对象或数组，RESTful API怎么设计？#

A：使用子资源端点，如POST /users/{userId}/orders。或者将嵌套对象序列化为JSON字段，在单个请求中包含完整结构。通常推荐前者保持语义清晰。

Q2：如何处理并发更新冲突？#

A：乐观锁方案：在表中增加version字段，更新时检查版本号。若版本不匹配返回409 Conflict。AI生成代码时可要求添加@Version注解（JPA）。

Q3：AI生成的代码可能存在SQL注入风险，怎么防范？#

A：强制要求使用参数化查询（如JPA、MyBatis的#{}），禁止字符串拼接SQL。可在prompt中明确“使用防SQL注入写法”，并在代码审查时重点检查。

Q4：15分钟内如果AI生成代码有bug，面试官会如何评判？#

A：更看重思路和解决问题的过程。你能识别出bug的位置、解释原因并提出修正方案，比完美无bug的代码更重要。建议先输出核心结构，再逐步完善验证逻辑。

总结#

本题考察AI辅助编程能力与RESTful规范掌握程度。关键在于：快速理解Schema、设计规范接口、生成可运行的代码骨架，并能解释验证、错误处理、并发控制等

关键点#

。AI工具是辅助，候选人的设计思路和问题排查能力才是评分核心。

现场实操：给定数据Schema生成符合RESTful规范的CRUD接口代码#

这是一道典型的现场实操题，考察候选人利用AI工具快速生成后端代码的能力。

在15分钟内完成，需要遵循以下步骤：

操作流程： 理解Schema：提取数据模型定义（字段、类型、约束、关系） 设计RESTful端点：

GET /resources - 列表查询（支持分页、过滤、排序）
POST /resources - 创建资源
GET /resources/{id} - 获取单个资源
PUT /resources/{id} - 全量更新
PATCH /resources/{id} - 部分更新
DELETE /resources/{id} - 删除资源 生成代码：使用AI工具（如Copilot、ChatGPT）输出控制器、服务层、数据访问层代码 解释关键逻辑：验证、错误处理、状态码选择、数据一致性

关键实现逻辑要点：

数据验证：使用DTO + 校验注解（如@Valid、@NotNull、@Size）
错误处理：全局异常处理器返回标准错误格式（如{“code”: 400, “message”: “...”}）
RESTful状态码：
201 Created（POST成功）
200 OK（GET/PUT/PATCH成功）
204 No Content（DELETE成功）
404 Not Found（资源不存在）
分页规范：使用page、size参数，返回{“data”: [], “total”: 100, “page”: 1, “size”: 20}

1
// Controller示例
2
@RestController
3
@RequestMapping("/api/users")
4
public class UserController {
5
@GetMapping
6
public Page<UserDTO> list(@PageableDefault Pageable pageable) { ... }
7

8
@PostMapping
9
@ResponseStatus(HttpStatus.CREATED)
10
public UserDTO create(@Valid @RequestBody UserCreateDTO dto) { ... }
11

12
@GetMapping("/{id}")
13
public UserDTO get(@PathVariable Long id) { ... }
14

15
@PutMapping("/{id}")
16
public UserDTO update(@PathVariable Long id, @Valid @RequestBody UserUpdateDTO dto) { ... }
17

18
@DeleteMapping("/{id}")
19
@ResponseStatus(HttpStatus.NO_CONTENT)
20
public void delete(@PathVariable Long id) { ... }
21
}

Show moreShow less

使用@Valid触发校验，MethodArgumentNotValidException处理
返回格式：{“field”: “email”, “message”: “邮箱格式不正确”}
明确约束：在prompt中包含Schema定义、技术栈（如Spring Boot 3 + JPA）、代码风格要求
分步生成：先生成实体类，再生成Repository、Service、Controller
人工修正：检查生成的业务逻辑是否正确，补充遗漏的验证规则

A：使用子资源端点，如POST /users/{userId}/orders。
或者将嵌套对象序列化为JSON字段，在单个请求中包含完整结构。
通常推荐前者保持语义清晰。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

AI_Generate_CRUD_Code_现场实操

这是一道典型的现场实操题，考察候选人利用AI工具快速生成后端代码的能力。在15分钟内完成，需要遵循以下步骤：

操作流程： 理解Schema：提取数据模型定义（字段、类型、约束、关系） 设计RESTful端点：

GET /resources - 列表查询（支持分页、过滤、排序）
POST /resources - 创建资源
GET /resources/{id} - 获取单个资源
PUT /resources/{id} - 全量更新
PATCH /resources/{id} - 部分更新
DELETE /resources/{id} - 删除资源 生成代码：使用AI工具（如Copilot、ChatGPT）输出控制器、服务层、数据访问层代码 解释关键逻辑：验证、错误处理、状态码选择、数据一致性

关键实现逻辑要点：

数据验证：使用DTO + 校验注解（如@Valid、@NotNull、@Size）
错误处理：全局异常处理器返回标准错误格式（如{“code”: 400, “message”: “...”}）
RESTful状态码：
201 Created（POST成功）
200 OK（GET/PUT/PATCH成功）
204 No Content（DELETE成功）
404 Not Found（资源不存在）
分页规范：使用page、size参数，返回{“data”: [], “total”: 100, “page”: 1, “size”: 20}

1
// Controller示例
2
@RestController
3
@RequestMapping("/api/users")
4
public class UserController {
5
@GetMapping
6
public Page<UserDTO> list(@PageableDefault Pageable pageable) { ... }
7

8
@PostMapping
9
@ResponseStatus(HttpStatus.CREATED)
10
public UserDTO create(@Valid @RequestBody UserCreateDTO dto) { ... }
11

12
@GetMapping("/{id}")
13
public UserDTO get(@PathVariable Long id) { ... }
14

15
@PutMapping("/{id}")
16
public UserDTO update(@PathVariable Long id, @Valid @RequestBody UserUpdateDTO dto) { ... }
17

18
@DeleteMapping("/{id}")
19
@ResponseStatus(HttpStatus.NO_CONTENT)
20
public void delete(@PathVariable Long id) { ... }
21
}

Show moreShow less

使用@Valid触发校验，MethodArgumentNotValidException处理
返回格式：{“field”: “email”, “message”: “邮箱格式不正确”}
明确约束：在prompt中包含Schema定义、技术栈（如Spring Boot 3 + JPA）、代码风格要求
分步生成：先生成实体类，再生成Repository、Service、Controller
人工修正：检查生成的业务逻辑是否正确，补充遗漏的验证规则

A：使用子资源端点，如POST /users/{userId}/orders。或者将嵌套对象序列化为JSON字段，在单个请求中包含完整结构。通常推荐前者保持语义清晰。
Q2：如何处理并发更新冲突？#
A：乐观锁方案：在表中增加version字段，更新时检查版本号。若版本不匹配返回409 Conflict。AI生成代码时可要求添加@Version注解（JPA）。
Q3：AI生成的代码可能存在SQL注入风险，怎么防范？#
本文已做格式统一与噪声清理，保留原始语义。
在15分钟内完成，需要遵循以下步骤：
1. 理解Schema：提取数据模型定义（字段、类型、约束、关系）
1. 设计RESTful端点：
- GET /resources - 列表查询（支持分页、过滤、排序）
- POST /resources - 创建资源
本文已做格式统一与噪声清理，保留原始语义。

AI｜985硕校招｜阿里淘天AI应用开发二三面已offer

Wed, 10 Jun 2026 00:00:00 GMT

AI｜985硕校招｜阿里淘天AI 应用开发二三面已offer#

来源：面经哥（微信公众号）
发布时间：2026年5月19日
采集时间：2026-06-05

个人背景#

211本科，985硕

二面#

全程不到 60 分钟，没有手撕代码，也没有问常规 Java 八股。

一、自我介绍#

自我介绍一下。
和同龄人相比，你觉得自己的专业优势和不足分别是什么？

二、AI 相关问题#

你怎么看待 AI？平时会在哪些场景中使用 AI？
平时常用哪些 AI 工具？为什么会选择这些工具？比如 GPT、Claude、Gemini 等。
你对 Open Claw 有哪些了解？你认为它的核心亮点是什么？

三、工程与安全问题#

在海量数据场景下，数据库可以从哪些方向进行优化？比如分库分表、缓存策略等。
项目中如果涉及隐私数据，你会如何保障隐私安全？

四、项目提问#

Agent 项目的开发背景是什么？核心功能有哪些？
Agent 的完整技术链路是怎样的？实际使用反馈如何？和市面上的 AI 产品相比，你觉得它有哪些优势、不足，以及后续改进方向？
如果要从 Skill 升级为 AI Agent，关键设计点是什么？
实习经历相关提问。（这部分问了大概十几分钟，具体内容略）

五、反问环节#

阿里淘天目前的技术栈构成是怎样的？
为什么这轮没有重点考察 Java 知识点和项目细节？
面试结果大概多久会出？

三面#

面试感受：有些问的还有点难度，感觉没完全答到面试官想要的。

一、Agent 提问#

你在 AI Agent 相关方向的学习情况如何？比如神经网络、深度学习等课程是否有过系统学习经历？
如果要设计一个面向电商运营小二的 AI Agent，用来完成活动海报文案生成、商品卖点提炼、促销策略建议这三类任务，你会怎么设计？
在这个 AI Agent 的设计中，为什么会选择 Skill 方案？
针对活动海报文案生成、商品卖点提炼、促销策略建议这三类任务，哪些环节需要调用工具？具体会调用哪些工具？
如果 AI Agent 的输出结果不稳定，你会优先排查哪些方面？
你会如何设定 AI Agent 的评测目标？
最近 3 个月重点学习了哪些新技术？你是通过什么方式学习的？为什么会重点学习这些内容？
你认为 OpenClaw 核心解决的是什么问题？它的边界和局限在哪里？
OpenClaw 主要从哪些层面尝试解决安全性问题？其中，指令清洗是如何实现的？

面试特点总结#

二面：偏综合考察，AI 视角 + 工程安全 + 项目深挖，无手撕代码，无 Java 八股
三面：重点考察 AI Agent 设计能力，围绕电商场景的 Agent 架构设计、工具调用、评测体系、安全性等展开
共同关注点：OpenClaw、Agent 项目经验、AI 工具使用习惯

AI面试模拟练习清单

Wed, 10 Jun 2026 00:00:00 GMT

🎯 AI Agent 开发 · 面试模拟练习清单#

📅 生成时间：2026-06-03 📚 来源：基于 19 份面经 + 秋招复习笔记 🎯 适用：AI 应用开发 / Agent 开发 / 大模型应用校招岗位

一、各大厂岗位核心要求（基于面经提炼）#

🏢 字节跳动（AI Agent 开发）#

扎实的 Agent 项目经验，能说清动机、挑战、迭代过程
了解主流 Agent 框架（LangChain、CrewAI、AutoGPT 等）
熟悉 LLM 上下文工程（Context Window、压缩策略）
能设计 Memory 机制（短/长期记忆、工作记忆）
掌握幻觉防御体系（多层级）
Prompt 工程能力（模块化、版本管理）
Agent 评测与优化验证能力（四层评测体系）
代码能力：Java/Python + 算法基础

🏢 阿里淘天（AI 应用开发）#

Agent 四大核心组件理解（规划/记忆/工具/执行）
会话压缩与上下文管理
长期记忆设计与写入策略
agent.md vs memory.md vs skills.md 职责区分
工具与 Skill 机制设计
Java 基础扎实（HashMap、线程池、并发）
Agent 评测体系

🏢 腾讯（大模型应用开发）#

一面：概念扎实（Agent、RAG、Prompt Engineering）
二面（系统设计）：Planner 设计、上下文优先级、异常处理、可审计 Agent
能回答”为什么不这么做”层面（深度思考）
技术选型的 Trade-off 分析

🏢 滴滴（AI 全栈开发）#

MCP 协议深度理解（运作方式、协议对比、并发处理）
AI Coding Tools 了解程度
MCP vs Skill 区别
前端+后端基础
智能体三要素

🏢 通用要求#

Agent 四种范式对比（Tool Use / ReAct / Plan-and-Execute / Multi-Agent）
RAG 完整链路（Chunking → Embedding → 检索 → Rerank）
Function Calling / Tool Use 流程
多 Agent 架构设计
工程化与可靠性设计（异常处理、性能优化、Token 优化）
算法基础（LeetCode Hot 100）

二、高频面试题清单（分模块，共 20 题）#

【Agent 核心概念】5 题#

什么是 Agent？它与普通 LLM 应用的本质区别是什么？
Agent 的四大核心组件是什么？分别做什么？
ReAct、Plan-and-Execute、Tool Use、Multi-Agent 四种范式如何对比？它们是线性进化关系吗？
多 Agent 架构有哪几种通信模式？各有什么优缺点？
Agent 的长短期记忆是怎么设计的？写入和检索的策略是什么？

【RAG 系统】3 题#

RAG 的完整链路是什么？每个环节的关键点是什么？
RAG 有哪些常见的优化手段？
RAG 和微调（Fine-tuning）的适用场景有什么区别？什么时候不应该上 RAG？

【MCP 协议】3 题#

MCP 协议是什么？它的工作原理是怎样的？
MCP 和 Function Calling 有什么区别和联系？
MCP 和 Skill 机制的区别是什么？

【工程实践】4 题#

怎么减少 Agent 的幻觉？请从多个层面说明。
Prompt 是怎么构建和优化的？结构化 Prompt 的设计原则是什么？
会话压缩怎么做？什么时候触发？
Agent 的评测体系怎么设计？评估哪些维度？

【项目面试话术】3 题#

请介绍你做过的一个 Agent 项目（用”业务痛点→初版方案→踩坑迭代→量化收益”结构）
这个设计你是怎么考虑的？有没有考虑过其他方案？
遇到过什么问题？怎么解决的？

【算法/CS 基础】2 题#

线程池的核心参数有哪些？怎么设计一个合适的线程池？
简单讲一下 Transformer 的流程和注意力机制。

三、逐题标准答案#

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

参考标准答案（面试风格）：

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

与普通 LLM 应用的本质区别（从 4 个维度）：

维度	普通 LLM 应用	Agent
交互模式	被动一问一答，用户每步引导	目标驱动，自主规划执行
工具调用	❌ 无，只能输出文本	✅ 调用 API / 操作文件 / 控制浏览器等
记忆系统	仅对话上下文	短期记忆 + 长期记忆 + 工作记忆
核心循环	单次推理 → 输出	Observe → Think → Act → Observe… 循环

核心架构公式：

Agent = LLM(Brain) + Planning + Memory + Tool Use

面试加分比喻：

普通 LLM 是”知识渊博的顾问”——你问什么他答什么； Agent 是”能自己干活的员工”——你说”分析这份报告做成 PPT 发我邮箱”，他自己查资料、分析、做 PPT、发邮件，不需要你一步步指挥。

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

参考标准答案（面试风格）：

Agent 的四大核心组件通常有两种划分方式，面试回答推荐用第一种：

方式一（阿里淘天面经考察版本）：

组件	功能	面试要点
① 规划 (Planning)	将复杂任务拆解为子目标；通过 CoT / ToT 等方法推理；具备自我反思（Self-Reflection）修正行为	不只是”计划”，还要提 CoT、ReAct 等推理范式
② 记忆 (Memory)	短期记忆=上下文窗口（In-Context Learning）；长期记忆=向量数据库+检索（用于跨会话知识沉淀）	区分短期/长期，面试常问”记忆写入和检索策略”
③ 工具使用 (Tool Use)	调用外部 API / 数据库 / 浏览器 / 文件系统等，弥补模型权重无法存储实时或专有数据的局限	核心是 Function Calling / MCP 协议
④ 执行 (Execution / Acting)	协调规划与执行之间的循环，将规划结果转化为实际动作，处理异常和重试	面试官常追问”出现异常怎么处理”

方式二（Lilian Weng 经典框架）：

LLM (Brain) + Planning + Memory + Tool Use 即把 LLM 本身作为”大脑”组件，负责理解指令、推理决策、生成输出。

你本次回答的评价：

要点	评价	说明
工具→操作外部环境	✅ 正确	抓住了核心功能
记忆→记住用户要求	⚠️ 太窄	记忆不只是”记住用户要求”，还包括短期记忆（上下文）、长期记忆（知识）、工作记忆（当前任务状态）
规划→计划每一步	✅ 基本正确	可以补充”任务拆解 + 自我反思”
缺第四个组件	❌ 漏了	第四个是执行 (Execution) 或 LLM 大脑本身

面试加分总结句：

“Agent = LLM(Brain) + Planning + Memory + Tool Use，这四个组件通过 ReAct 循环（Observe→Think→Act→Observe…）协同工作，LLM 是大脑，规划拆解目标，记忆提供知识上下文，工具负责改变外部世界。”

💡 练习方式：我会逐题提问，你回答后我帮你判断正确性，查资料补充完善。

Compaction OpenClaw 策略整理

Wed, 10 Jun 2026 00:00:00 GMT

Compaction_OpenClaw_策略#

问题#

Compaction_OpenClaw_策略

标准回答#

当对话历史太长、裁剪不够用时：Compaction（压缩）及 OpenClaw 策略#

Compaction（压实/压缩）：当裁剪（直接丢早期消息）已经不够用时，换用？ LLM 把一大段对话历史压缩成一段精炼摘要，用摘要替换原始消息。这样大幅缩减 token 占用，但关键信息（决策、待办、结论）仍保留。

OpenClaw 的 Compaction 核心流程（4 步）： 分块 (Chunking)：按 token 预算切分消息（默认 2 段），保留最近 3 轮对话原文，只压缩更早的历史。 逐块摘要：每个 chunk 分别发给 LLM 生成摘要；若单条消息超大（>50% 窗口），降级处理（跳过超大消息并标注省略）。 合并摘要：再次调用 LLM 将多段局部摘要融合成一份最终摘要，要求保留：任务状态、进度、用户最后请求、决策及原因、待办、约束条件。 摘要增强：追加额外上下文，包括工具调用失败记录（exit code + error）、文件操作记录、最近几轮原文摘要、从 AGENTS.md 提取的关键规则。

最终摘要替换原始消息并写回会话历史。设计理念：宁可多花 token 调用 LLM 做摘要，也不丢关键信息。

扩展知识#

1. 摘要质量检查与重试#

质量审计（默认关闭，需显式启用）检查摘要是否包含 5 个必要章节：Decisions、Open TODOs、Constraints/Rules、Pending user asks、Exact identifiers。
启用后若审计失败，会触发重试（最多 3 次）。
即使未启用审计，prompt 也会要求结构化章节。

2. 标识符严格保留策略#

LLM 容易把 UUID、文件路径、API key 等概括掉。OpenClaw 默认采用 strict 策略，要求摘要中原样保留所有不可重构的标识符（如文件名、URL、hash、端口等），并在摘要中包含 Exact identifiers 章节。

3. Memory Flush 联动#

在接近 Compaction 阈值时，会先触发一次额外 Agent 轮次（Memory Flush），让模型主动把重要信息写入 memory/YYYY-MM-DD.md 长期存储。相当于“考前再检查一遍”，防止压缩丢失关键信息。

4. Post-compaction Context 注入#

压缩完成后，从 AGENTS.md 重新注入 “Session Startup” 和 “Red Lines” 两部分，避免模型遗忘红线规则。

5. 工具调用失败信息保留#

Compaction 会专门提取并保留工具调用失败信息（exit code + error）。避免 Agent 压缩后重复尝试已知不可行的路径。

面试官追问#

Q1：Compaction 本身也要调 LLM，token 开销大吗？#

A：单次 Compaction 消耗几千 token，但能把几万 token 的历史压缩到几千 token 的摘要，后续每轮都省大量 token。长对话收益显著，总 token 消耗远低于不做压缩。

Q2：分段摘要的 chunk 大小怎么定？#

A：按模型 Context 窗口的 40% 为基准，自适应调整（最低 15%），预留约 4096 token 给摘要 prompt。在消息边界切分，不跨消息。跨 chunk 的上下文关联靠合并摘要阶段弥补。

Q3：Compaction 触发时机？#

A：按 token 数触发，每次组装 prompt 前计算当前历史占比，超过阈值即触发。不用固定轮次，因为每轮长度差异大。

Q4：strict 策略保留标识符会不会导致摘要膨胀？#

A：会，但标识符通常只占几十 token，相比丢失标识符后任务失败再重试的代价，成本低得多。过时标识符可在 Memory Flush 阶段由 Agent 主动清理。

关键点#

当对话历史太长、裁剪不够用时：Compaction（压缩）及 OpenClaw 策略#

Compaction（压实/压缩）：当裁剪（直接丢早期消息）已经不够用时，换用 LLM 把一大段对话历史压缩成一段精炼摘要，用摘要替换原始消息。

这样大幅缩减 token 占用，但关键信息（决策、待办、结论）仍保留。
OpenClaw 的 Compaction 核心流程（4 步）： 分块 (Chunking)：按 token 预算切分消息（默认 2 段），保留最近 3 轮对话原文，只压缩更早的历史。
1. 逐块摘要：每个 chunk 分别发给 LLM 生成摘要；若单条消息超大（>50% 窗口），降级处理（跳过超大消息并标注省略）。
1. 合并摘要：再次调用 LLM 将多段局部摘要融合成一份最终摘要，要求保留：任务状态、进度、用户最后请求、决策及原因、待办、约束条件。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Compaction_OpenClaw_策略

Compaction（压实/压缩）：当裁剪（直接丢早期消息）已经不够用时，换用 LLM 把一大段对话历史压缩成一段精炼摘要，用摘要替换原始消息。这样大幅缩减 token 占用，但关键信息（决策、待办、结论）仍保留。

OpenClaw 的 Compaction 核心流程（4 步）： 分块 (Chunking)：按 token 预算切分消息（默认 2 段），保留最近 3 轮对话原文，只压缩更早的历史。
1. 逐块摘要：每个 chunk 分别发给 LLM 生成摘要；若单条消息超大（>50% 窗口），降级处理（跳过超大消息并标注省略）。
1. 合并摘要：再次调用 LLM 将多段局部摘要融合成一份最终摘要，要求保留：任务状态、进度、用户最后请求、决策及原因、待办、约束条件。
1. 摘要增强：追加额外上下文，包括工具调用失败记录（exit code + error）、文件操作记录、最近几轮原文摘要、从 AGENTS.md 提取的关键规则。
本文已做格式统一与噪声清理，保留原始语义。
LLM 把一大段对话历史压缩成一段精炼摘要，用摘要替换原始消息。这样大幅缩减 token 占用，但关键信息（决策、待办、结论）仍保留。
OpenClaw 的 Compaction 核心流程（4 步）：
1. 分块 (Chunking)：按 token 预算切分消息（默认 2 段），保留最近 3 轮对话原文，只压缩更早的历史。
1. 逐块摘要：每个 chunk 分别发给 LLM 生成摘要；若单条消息超大（>50% 窗口），降级处理（跳过超大消息并标注省略）。
1. 合并摘要：再次调用 LLM 将多段局部摘要融合成一份最终摘要，要求保留：任务状态、进度、用户最后请求、决策及原因、待办、约束条件。
本文已做格式统一与噪声清理，保留原始语义。

Context Engine Abstraction 整理

Wed, 10 Jun 2026 00:00:00 GMT

Context_Engine_Abstraction#

问题#

Context_Engine_Abstraction

标准回答#

OpenClaw 的可插拔 Context Engine：为什么需要抽象？#

支持哪些策略？

核心原因：Context 管理没有万能方案。 不同的应用场景、模型窗口大小、任务类型，最优策略差异巨大。将 Context 管理抽象成接口（定义“做什么”），让策略实现（“怎么做”）可独立替换，既方便内部迭代，也方便社区扩展。这是经典的策略模式。

OpenClaw 的 ContextEngine 接口覆盖完整生命周期：

阶段	方法	作用
初始化	`bootstrap`	会话首次创建时初始化（如导入历史）
存消息	`ingest`/`ingestBatch`	新消息进来时如何存储、是否做额外处理（如向量化）
挑消息	`assemble`	发给模型前，在 token 预算内挑选最合适的消息
压消息	`compact`	历史太长时如何压缩（摘要、裁剪、归档）
轮后处理	`afterTurn`	每轮对话结束后的收尾工作（持久化、触发后台压缩）
子 Agent	`prepareSubagentSpawn`/`onSubagentEnded`	管理子 Agent 的上下文隔离与回收
销毁	`dispose`	释放引擎持有的资源

核心调度逻辑只依赖这套接口，不关心具体实现。通过 registerContextEngine(id, factory) 注册新引擎，在配置中通过 plugins.slots.contextEngine 一行切换，无需改动核心代码。

支持的不同策略方向：

默认 legacy 策略：全部塞进去，塞不下线性压缩最早消息，简单粗暴
基于检索的 RAG 策略：消息入库时向量化，组装时按语义相关性捞历史，适合长对话多话题场景
分层存储策略：冷热分离，最近几轮放内存、摘要放本地、更早的放云端，按需拉取
任务感知策略：根据当前任务类型（写代码 vs 闲聊）动态决定保留哪些历史，提升 token 预算质量
自定义压缩策略：通过 ownsCompaction 标记接管压缩，可实现树状摘要、按话题分支压缩等高级方式

扩展知识#

1. 内置的 legacy 引擎#

当前默认引擎，实现直白：

ingest 是 no-op（消息持久化由 SessionManager 负责）
assemble 直接透传消息列表，不做筛选
compact 委托给 compactEmbeddedPiSessionDirect() 做线性压缩

策略粗糙：“全部塞进去，塞不下压缩最早的”。短对话够用，长对话或多话题场景效果不佳。

2. 高级策略详解#

基于检索的 Context Engine（RAG 风格）

ingest 时向量化每条消息，存入向量库
assemble 时不按时间顺序，而是根据当前 query 做语义检索，捞最相关的历史片段
对跨多天、换过多个话题的长对话，比线性截断有效得多

分层存储引擎（冷热分离）

热数据：最近 3-5 轮对话，直接放内存
温数据：最近几个 compaction 周期的摘要，放本地文件
冷数据：更早的历史，可扔外部存储甚至云端
assemble 时按需从不同层拉取，保证最近上下文完整，又不撑爆内存

任务感知引擎

根据当前任务类型动态调整组装策略
写代码时：优先保留代码相关历史、文件路径、报错信息
闲聊时：优先保留情感偏好和个人信息
相同 token 预算，内容质量更高

自定义 Compaction 引擎

接口中的 ownsCompaction: true 标记让引擎完全接管压缩策略
默认线性压缩是”最早消息一坨压成摘要”
可替换为树状摘要：按话题分支组织，每个分支独立压缩，保留更多结构化信息

3. 插件注册机制#

切换过程对核心代码零侵入：实现 ContextEngine 接口调用 registerContextEngine("my-engine-id", factory) 注册配置文件里将 plugins.slots.contextEngine 指向引擎 ID

类比 Webpack plugin 体系、VS Code 扩展机制。

面试官追问#

Q1：legacy 引擎的 ingest 是 no-op，消息谁在管？换成 RAG 引擎职责怎么迁移？#

A：legacy 引擎的消息持久化由 SessionManager 负责。换成 RAG 引擎后，ingest 需真正接管消息处理（至少做向量化和入库）。迁移关键是 SessionManager 需让出”写消息”动作，或双方做好协调避免重复写。这正是抽象成接口的原因——职责边界可随引擎实现灵活调整。

Q2：assemble 时 token 预算给得很紧，不同引擎的降级策略有何差异？#

A：

legacy 引擎：暴力从最早消息开始砍，砍到塞下为止
RAG 引擎：按相关性排序，预算紧就少捞几条，质量衰减平滑
分层存储引擎：优先砍冷数据层，保住热数据
任务感知引擎：根据任务权重动态决定哪些历史先丢（如写代码时闲聊记录优先级最低）

Q3：ownsCompaction 标记具体怎么生效？不设标记时压缩谁触发？#

A：压缩触发分两层：

不设 ownsCompaction：底层 Pi runtime 内置 auto-compaction 监控 token 用量，超阈值自动压缩，外层 Runner 不介入
设 ownsCompaction: true：Pi 的内置 auto-compaction 被禁用，改由引擎通过 afterTurn 等钩子自主决定压缩时机和方式
兜底机制：无论是否设标记，Runner 在上下文快炸时会直接调 contextEngine.compact() 做紧急压缩

ownsCompaction 控制”日常谁来管压缩”，但”快炸了”时 Runner 一定会兜底。这对有自己存储和索引体系的引擎特别重要。

关键点#

OpenClaw 的可插拔 Context Engine：为什么需要抽象？#
支持哪些策略？
核心回答#

**核心原因：Context 管理没有万能方案。

** 不同的应用场景、模型窗口大小、任务类型，最优策略差异巨大。
将 Context 管理抽象成接口（定义“做什么”），让策略实现（“怎么做”）可独立替换，既方便内部迭代，也方便社区扩展。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Context_Engine_Abstraction

OpenClaw 的可插拔 Context Engine：为什么需要抽象？支持哪些策略？#

核心回答#

OpenClaw 的 ContextEngine 接口覆盖完整生命周期：

阶段	方法	作用
初始化	`bootstrap`	会话首次创建时初始化（如导入历史）
存消息	`ingest`/`ingestBatch`	新消息进来时如何存储、是否做额外处理（如向量化）
挑消息	`assemble`	发给模型前，在 token 预算内挑选最合适的消息
压消息	`compact`	历史太长时如何压缩（摘要、裁剪、归档）
轮后处理	`afterTurn`	每轮对话结束后的收尾工作（持久化、触发后台压缩）
子 Agent	`prepareSubagentSpawn`/`onSubagentEnded`	管理子 Agent 的上下文隔离与回收
销毁	`dispose`	释放引擎持有的资源

支持的不同策略方向：
默认 legacy 策略：全部塞进去，塞不下线性压缩最早消息，简单粗暴
基于检索的 RAG 策略：消息入库时向量化，组装时按语义相关性捞历史，适合长对话多话题场景
分层存储策略：冷热分离，最近几轮放内存、摘要放本地、更早的放云端，按需拉取
任务感知策略：根据当前任务类型（写代码 vs 闲聊）动态决定保留哪些历史，提升 token 预算质量
自定义压缩策略：通过 ownsCompaction 标记接管压缩，可实现树状摘要、按话题分支压缩等高级方式

当前默认引擎，实现直白：

ingest 是 no-op（消息持久化由 SessionManager 负责）
assemble 直接透传消息列表，不做筛选
compact 委托给 compactEmbeddedPiSessionDirect() 做线性压缩

策略粗糙：“全部塞进去，塞不下压缩最早的”。短对话够用，长对话或多话题场景效果不佳。

2. 高级策略详解#

基于检索的 Context Engine（RAG 风格）

ingest 时向量化每条消息，存入向量库
assemble 时不按时间顺序，而是根据当前 query 做语义检索，捞最相关的历史片段
对跨多天、换过多个话题的长对话，比线性截断有效得多

分层存储引擎（冷热分离）

热数据：最近 3-5 轮对话，直接放内存
温数据：最近几个 compaction 周期的摘要，放本地文件
冷数据：更早的历史，可扔外部存储甚至云端
assemble 时按需从不同层拉取，保证最近上下文完整，又不撑爆内存

任务感知引擎

根据当前任务类型动态调整组装策略
写代码时：优先保留代码相关历史、文件路径、报错信息
闲聊时：优先保留情感偏好和个人信息
相同 token 预算，内容质量更高

自定义 Compaction 引擎

接口中的 ownsCompaction: true 标记让引擎完全接管压缩策略
默认线性压缩是”最早消息一坨压成摘要”
可替换为树状摘要：按话题分支组织，每个分支独立压缩，保留更多结构化信息

切换过程对核心代码零侵入：实现 ContextEngine 接口调用 registerContextEngine("my-engine-id", factory) 注册配置文件里将 plugins.slots.contextEngine 指向引擎 ID

类比 Webpack plugin 体系、VS Code 扩展机制。

本文已做格式统一与噪声清理，保留原始语义。
核心原因：Context 管理没有万能方案。 不同的应用场景、模型窗口大小、任务类型，最优策略差异巨大。将 Context 管理抽象成接口（定义“做什么”），让策略实现（“怎么做”）可独立替换，既方便内部迭代，也方便社区扩展。这是经典的策略模式。
OpenClaw 的 ContextEngine 接口覆盖完整生命周期：
| 阶段 | 方法 | 作用 |
|------|------|------|
| 初始化 | bootstrap | 会话首次创建时初始化（如导入历史） |
本文已做格式统一与噪声清理，保留原始语义。

Context Window 核心约束与处理策略整理

Wed, 10 Jun 2026 00:00:00 GMT

Context_Window_核心约束与处理策略#

问题#

Context_Window_核心约束与处理策略

标准回答#

Agent 的 Context Window：核心约束与处理策略#

什么是 Context Window？#

Context Window（上下文窗口）是大语言模型（LLM）单次请求能处理的最大 token 数量。Token 是模型处理文本的最小单位，英文约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token。

为什么是 Agent 工程中最核心的约束？

Agent 的上下文里塞的东西太多：

System Prompt（2000-5000 token）
工具定义列表（每个 200-500 token，20 个工具就是 4000-10000 token）
完整对话历史
每次工具调用的入参和返回结果
模型回复预留空间

一次 Agent 运行可能跑几十轮，每一轮结果都追加到历史中，Context 像滚雪球一样越来越大。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 行为变得不可预测。

扩展知识#

1. Context Window 里到底塞了什么？#

以典型编程 Agent 为例：

固定开销：System Prompt + 工具定义，每次请求都得带，约 6000-15000 token
对话历史：每调一次工具增加两条消息（tool_call + tool_result）。工具返回一个文件内容可能占 3000-8000 token。跑 10 轮，历史轻松突破 50K token。

OpenClaw 在 src/agents/context.ts 中将这些组成部分拆分，按优先级管理空间占用。

2. OpenClaw 的 Context Window 管理机制#

窗口大小确定优先级（从高到低）： modelsConfig 用户显式指定的值模型注册表自动发现的值默认 128K token agents.defaults.contextTokens 做全局上限截断

两道防线：

硬下限：CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于此值拒绝运行
软告警：CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于此值警告用户

检测到 overflow 时的渐进式处理：先尝试 compaction（压缩早期对话历史为摘要）再尝试截断过大的 tool result（保留头尾加摘要）最后报错，建议用户 /reset 或换更大窗口的模型

3. 主流的 Context 管理策略#

策略	做法	优点	缺点
滑动窗口	只保留最近 N 轮对话	实现简单	易丢失任务关键信息（如最初需求）
摘要压缩	用额外 LLM 调用压缩长对话	效果好	延迟 + token 成本，可能丢失细节
分层存储	按优先级分级：System + 最近2轮永久保留，中间做摘要，大文本截断	平衡保真度和空间	实现复杂
外部检索	历史存向量数据库，每轮检索相关片段	适合超长会话	检索质量依赖 embedding

实际生产：混合使用，不依赖单一策略。

4. Token 计算的坑#

同样长度中文比英文 token 开销高 2-3 倍
不同模型的 tokenizer 不同，同一段文本在 GPT 和 Claude 中 token 数可能差 10%-20%
OpenClaw 做法：用各模型对应的 tokenizer 精确计算，留出 10% 安全余量

面试官追问#

Q1：实现 compaction 机制时，摘要格式怎么设计？哪些信息不能丢？#

必须保留三类信息：用户的原始任务目标已经完成了哪些关键步骤当前的执行状态和中间产物

格式建议：结构化文本，分块标注，方便 LLM 快速抓重点。

最忌讳：丢了任务目标 → Agent 压缩完不知道自己在干嘛。

示例（调试 bug 场景）：

用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败。

Q2：不同模型的 Context Window 差异很大，怎么处理兼容性？#

核心思路：自适应。

Agent 启动时查模型注册表拿到窗口大小
动态计算固定开销占多少，留给对话历史的空间有多少
小模型（如 8K）更要激进压缩，甚至限制可注册的工具数量
OpenClaw 设硬下限 16K token，低于此值拒绝运行
上层给用户推荐清单，标明每个模型适合跑的复杂度的任务

Q3：工具返回结果特别大时（如 1 万行日志），怎么处理？#

不能全塞（30K-50K token，一次吃大半窗口）。

处理思路：按需截断 + 智能提取

最简单：设 tool result token 上限，超了就保留头尾各几百行 + “中间省略 N 行” 标记
更聪明：截断前让 LLM 做一轮 relevance extraction，只留与当前任务相关的内容
OpenClaw 在 context-window-guard 中有类似处理，优先截断大的 tool result（最“胖”也最容易压缩）

总结#

Context Window 是 Agent 工程的物理瓶颈。优秀的管理策略不是单点优化，而是组合使用滑动窗口、摘要压缩、分层存储、外部检索等多种手段，并根据模型能力自适应调整。OpenClaw 的渐进式降级（compaction → 截断 → 报错）和精确 token 计算（含 10% 余量）是值得参考的实践。

关键点#

算力够，但装不下那么多信息。工程上必须主动管理，而不是被动等溢出报错。

Agent 的 Context Window：核心约束与处理策略#
Context Window（上下文窗口）是大语言模型（LLM）单次请求能处理的最大 token 数量。
Token 是模型处理文本的最小单位，英文约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token。
**为什么是 Agent 工程中最核心的约束？
**

Agent 的上下文里塞的东西太多：

System Prompt（2000-5000 token）
工具定义列表（每个 200-500 token，20 个工具就是 4000-10000 token）
完整对话历史
每次工具调用的入参和返回结果
模型回复预留空间

一次 Agent 运行可能跑几十轮，每一轮结果都追加到历史中，Context 像滚雪球一样越来越大。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Context_Window_核心约束与处理策略

Context Window（上下文窗口）是大语言模型（LLM）单次请求能处理的最大 token 数量。Token 是模型处理文本的最小单位，英文约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token。
为什么是 Agent 工程中最核心的约束？

Agent 的上下文里塞的东西太多：

System Prompt（2000-5000 token）
工具定义列表（每个 200-500 token，20 个工具就是 4000-10000 token）
完整对话历史
每次工具调用的入参和返回结果
模型回复预留空间

以典型编程 Agent 为例：
固定开销：System Prompt + 工具定义，每次请求都得带，约 6000-15000 token
对话历史：每调一次工具增加两条消息（tool_call + tool_result）。工具返回一个文件内容可能占 3000-8000 token。跑 10 轮，历史轻松突破 50K token。
本文已做格式统一与噪声清理，保留原始语义。
Context Window（上下文窗口）是大语言模型（LLM）单次请求能处理的最大 token 数量。Token 是模型处理文本的最小单位，英文约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token。
为什么是 Agent 工程中最核心的约束？
Agent 的上下文里塞的东西太多：
- System Prompt（2000-5000 token）
- 工具定义列表（每个 200-500 token，20 个工具就是 4000-10000 token）
本文已做格式统一与噪声清理，保留原始语义。

Contextual Query Augmentation 整理

Wed, 10 Jun 2026 00:00:00 GMT

Contextual_Query_Augmentation#

问题#

Contextual_Query_Augmentation

标准回答#

1
### 3？
2
空上下文处理策略
3
当检索不到相关文档时，系统需要优雅降级：
4
- **保守策略**：指示模型不要回答（默认行为）
5
- **自定义策略**：通过自定义模板引导模型给出友好提示，避免生成幻觉内容
6
- **混合策略**：允许模型基于自身知识回答，但明确告知信息来源
7

8
---
9

10
## 面试官追问
11

12
### Q1：上下文查询增强和查询重写有什么区别？
13
**A**：
14
- **查询重写**：修改用户查询本身，使其更适合检索（如扩写、缩写、纠错）
15
- **上下文查询增强**：将原始查询与检索到的文档拼接，形成完整的 prompt
16
- **关系**：查询重写发生在检索前，上下文查询增强发生在检索后、生成前
17

18
### Q2：如何避免增强后的 prompt 超过 token 限制？
19
**A**：
20
- 对检索到的文档做截断或摘要（保留最相关的片段）
21
- 使用动态窗口，根据可用 token 预算调整注入的文档数量
22
- 采用滑动窗口或重排序，只保留 top-k 最相关的文档
23

24
### Q3：上下文查询增强和 RAG 是什么关系？
25
**A**：上下文查询增强是 RAG 流程中的一环。完整 RAG 流程为：
26
查询重写（预检索）
27
向量检索
28
**上下文查询增强**（将查询与检索结果结合）
29
LLM 生成回答
30

31
Spring AI 的 `RetrievalAugmentationAdvisor` 封装了这一流程，`ContextualQueryAugmenter` 专门负责增强步骤。
32

33
### Q4：如果检索到的文档包含矛盾信息，怎么办？
34
**A**：
35
- 在增强 prompt 中明确要求模型基于"最可信"的信息回答
36
- 使用重排序模型，将高置信度文档放在前面
37
- 让模型在回答中标注信息来源，或明确指出信息冲突
38

39
---
40

41
## 总结
42

43
上下文查询增强是连接检索和生成的桥梁，通过将检索到的文档与用户查询智能结合，显著提升 RAG 系统的回答质量。Spring AI 通过 `ContextualQueryAugmenter` 和空上下文处理机制，提供了灵活的实现方式，可优雅处理检索失败等边界情况。
44

45
##
46

47
## 关键点
48

49
- ```
50

51
### 3. 空上下文处理策略
52
当检索不到相关文档时，系统需要优雅降级：
53
- **保守策略**：指示模型不要回答（默认行为）
54
- **自定义策略**：通过自定义模板引导模型给出友好提示，避免生成幻觉内容
55
- **混合策略**：允许模型基于自身知识回答，但明确告知信息来源
56

57
---
58

59
- **A**：
60
- **查询重写**：修改用户查询本身，使其更适合检索（如扩写、缩写、纠错）
61
- **上下文查询增强**：将原始查询与检索到的文档拼接，形成完整的 prompt
62
- **关系**：查询重写发生在检索前，上下文查询增强发生在检索后、生成前
63

64
- **A**：
65
- 对检索到的文档做截断或摘要（保留最相关的片段）
66
- 使用动态窗口，根据可用 token 预算调整注入的文档数量
67
- 采用滑动窗口或重排序，只保留 top-k 最相关的文档
68

69
- **A**：上下文查询增强是 RAG 流程中的一环。
70
- 完整 RAG 流程为：
71
查询重写（预检索）
72
向量检索
73
**上下文查询增强**（将查询与检索结果结合）
74
LLM 生成回答
75

76
Spring AI 的 `RetrievalAugmentationAdvisor` 封装了这一流程，`ContextualQueryAugmenter` 专门负责增强步骤。
77

78
## 备注
79

80
- 本文已做格式统一与噪声清理，保留原始语义。
81
- ## 问题
82

83
Contextual_Query_Augmentation

Show moreShow less

当检索不到相关文档时，系统需要优雅降级：

保守策略：指示模型不要回答（默认行为）
自定义策略：通过自定义模板引导模型给出友好提示，避免生成幻觉内容
混合策略：允许模型基于自身知识回答，但明确告知信息来源

A：
查询重写：修改用户查询本身，使其更适合检索（如扩写、缩写、纠错）
上下文查询增强：将原始查询与检索到的文档拼接，形成完整的 prompt
关系：查询重写发生在检索前，上下文查询增强发生在检索后、生成前
A：
对检索到的文档做截断或摘要（保留最相关的片段）
使用动态窗口，根据可用 token 预算调整注入的文档数量
采用滑动窗口或重排序，只保留 top-k 最相关的文档
A：上下文查询增强是 RAG 流程中的一环。完整 RAG 流程为：查询重写（预检索）向量检索 上下文查询增强（将查询与检索结果结合） LLM 生成回答

Spring AI 的 RetrievalAugmentationAdvisor 封装了这一流程，ContextualQueryAugmenter 专门负责增强步骤。

Q4：如果检索到的文档包含矛盾信息，怎么办？#
本文已做格式统一与噪声清理，保留原始语义。
当检索不到相关文档时，系统需要优雅降级：
- 保守策略：指示模型不要回答（默认行为）
- 自定义策略：通过自定义模板引导模型给出友好提示，避免生成幻觉内容
- 混合策略：允许模型基于自身知识回答，但明确告知信息来源
Q1：上下文查询增强和查询重写有什么区别？#
本文已做格式统一与噪声清理，保留原始语义。

Embedding Model Selection 整理

Wed, 10 Jun 2026 00:00:00 GMT

Embedding_Model_Selection#

问题#

Embedding_Model_Selection

标准回答#

在 RAG 中如何选择 Embedding Model（嵌入模型）—— 考虑因素与选型指南#

选择 Embedding Model 核心看 7 个因素，可概？为”准、快、专、广、大、活、省”： 准（语义准确性）：模型能否精准捕捉文本语义，长句理解、上下文关联、同义词区分能力直接影响向量相似度计算的可靠性。 快（模型效率）：推理速度能否满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源。 专（领域适配）：是否针对垂直领域做过预训练或微调。例如金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材。 广（多语言支持）：是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能否正确嵌入。 大（数据规模匹配）：模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩。 活（开放性与生态）：是否开源、社区是否活跃、能不能定制化微调，API 调用是否灵活。 省（成本）：计算成本包括训练推理的硬件投入，使用成本包括第三方 API 的 token 费用和商用授权费。

扩展知识#

1. 语义准确性怎么评估#

通常用语义相似度任务评估，如 STS-B 数据集，看模型对同义句和反义句的向量距离是否合理。注意两点：

部分模型擅长短文本（如 Sentence-BERT），处理长文本时会丢失上下文，需选 RoBERTa 变种或 Longformer 类模型。
通用模型在专业领域可能词不达意，例如”主诉”在医疗文本中是专有名词，通用模型可能理解成”主要诉求”。

2. 领域适配的三种策略#

直接选领域专用模型：LegalBERT 用于法律文档，PubMedBERT 用于医学文献。
通用模型 + 领域数据微调：适合有私有语料的场景（如公司内部客服对话数据）。
添加领域适配器：用 LoRA 技术在不改变原模型的前提下新增少量参数适配领域。

真实案例：某电商场景的 RAG 用通用模型时，“SKU”、“客单价”等词嵌入效果很差，切换到零售领域预训练的模型后，召回准确率提升了 23%。

3. 多语言支持#

单语言模型：如 Chinese-BERT 只支持中文。
多语言模型：如 XLM-RoBERTa 支持 100+ 语言，但需分别处理。
跨语言模型：如 mBERT 基于双语对齐训练，中英句子嵌入在同一空间，适合翻译场景。
小语种：若无专用模型，用通用多语言模型 + 数据增强（如 multilingual T5 配合少量目标语言语料微调）。

4. 开源 vs 闭源的选择#

开源模型（如 Sentence-BERT）：可灵活修改代码，适合深度定制（如加入自定义分词器），但需自己解决部署和优化问题。
闭源 API（如 OpenAI Embedding、Cohere）：开箱即用，适合快速验证 MVP，但受限于厂商更新和费用（OpenAI 按 token 收费，长文本成本较高）。

面试官追问#

Q1：线上 QPS 很高，但又想保证语义准确性，怎么平衡？#

A：使用级联策略。

第一阶段：轻量模型快速召回 Top 100（如 MiniLM，毫秒级）。
第二阶段：重型模型对 Top 100 做精排（如 BERT-large，处理 100 条只需几百毫秒）。
另外可考虑模型蒸馏：用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。

Q2：怎么判断一个嵌入模型在你的业务场景下效果好不好？#

A：最靠谱的方式是构建评测数据集。

从业务数据里挑 500 到 1000 条 query，人工标注相关文档。
用 Recall@K、MRR 等指标评估召回效果。
不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和业务数据分布可能差很远。
可做 A/B 测试，看用户的点击率和满意度是否提升。

Q3：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？#

A：尝试以下方案： LoRA 微调：参数高效微调，几千条数据就能见效，训练成本低。 数据增强：用大模型改写现有数据，或用同义词替换、回译等方式扩大数据量。 领域词表预处理：把专业术语替换成通用模型能理解的描述（检索完再还原回来）。

总结#

选择 Embedding 模型需综合考量准确性、效率、领域适配、多语言支持、数据规模、开源生态和成本。实际业务中建议通过构建评测数据集和 A/B 测试来验证效果，避免仅依赖通用榜单。对于资源受限或专业术语强的场景，LoRA 微调、级联策略和领域词表预处理是实用技巧。

关键点#

在 RAG 中如何选择 Embedding Model（嵌入模型）—— 考虑因素与选型指南#

选择 Embedding Model 核心看 7 个因素，可概括为”准、快、专、广、大、活、省”： 准（语义准确性）：模型能否精准捕捉文本语义，长句理解、上下文关联、同义词区分能力直接影响向量相似度计算的可靠性。

2. 快（模型效率）：推理速度能否满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源。
1. 专（领域适配）：是否针对垂直领域做过预训练或微调。
例如金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材。
1. 广（多语言支持）：是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能否正确嵌入。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Embedding_Model_Selection

2. 快（模型效率）：推理速度能否满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源。
1. 专（领域适配）：是否针对垂直领域做过预训练或微调。例如金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材。
1. 广（多语言支持）：是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能否正确嵌入。
1. 大（数据规模匹配）：模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩。
本文已做格式统一与噪声清理，保留原始语义。
为”准、快、专、广、大、活、省”：
1. 准（语义准确性）：模型能否精准捕捉文本语义，长句理解、上下文关联、同义词区分能力直接影响向量相似度计算的可靠性。
1. 快（模型效率）：推理速度能否满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源。
1. 专（领域适配）：是否针对垂直领域做过预训练或微调。例如金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材。
1. 广（多语言支持）：是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能否正确嵌入。
本文已做格式统一与噪声清理，保留原始语义。

Fine Tuning 原理与场景整理

Wed, 10 Jun 2026 00:00:00 GMT

Fine_Tuning_原理与场景#

问题#

Fine_Tuning_原理与场景

标准回答#

大模型微调 (Fine-tuning) 原理与适用场景#

大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整？本质上是在通用知识的基础上“精雕细琢”，让模型在某个垂直领域表现得更专业。

微调的核心原理是迁移学习：预训练模型已在海量数据上学会语言通用规律，微调用少量领域数据让模型学会特定表达方式和知识。

什么时候需要微调而不是直接使用基础模型？#

专业领域应用：如医疗诊断、法律咨询，基础模型对专业术语掌握不够深。用10万条专科病历数据微调，准确率可从60%提到90%以上。 数据安全要求高：金融机构、政府部门内部数据不能传到云端 API，只能把开源模型（LLaMA、Qwen）拉下来在本地机房微调部署。 特定任务需要稳定输出：客服机器人、代码补全等场景，Prompt工程输出不稳定、token消耗大。微调一版专用模型，响应快、成本低、格式稳定。

扩展知识#

1. 微调的底层原理#

预训练：TB级文本自回归训练，学习“预测下一个词”。消耗几千张A100跑数月，成本千万美元。
微调：学习率通常比预训练低1-2个数量级（预训练1e-4 → 微调1e-5或2e-6），防止灾难性遗忘。
数据量：全参数微调需1-10万条高质量样本；LoRA等参数高效方法几千条即可。

2.#

主流微调方法对比#

方法	可训练参数占比	显存需求（7B模型）	适用场景
全参数微调	100%	80GB+	追求极致效果，资源充足
LoRA	0.1%-1%	24GB	资源有限，多任务切换
QLoRA	0.1%-1%	12GB	消费级显卡，个人开发者
Adapter	1%-5%	30GB	需要频繁切换任务

3.#

微调 vs Prompt 工程 vs RAG#

Prompt工程：快速验证，无需训练。缺点：token消耗大，context window有限。
RAG：适合知识库场景，知识实时更新。缺点：检索质量依赖 embedding，复杂推理能力不足。
微调：适合模型能力本身不够的情况（特定推理模式、输出格式、领域术语）。知识直接编码进参数，推理无需额外context。

实际项目常组合使用：先微调领域模型，再用RAG补充实时知识，最后用Prompt控制输出格式。

4.#

实践中的坑#

数据质量比数量重要：1000条高质量 instruction 数据，效果可能超10万条噪声数据。 验证集要有代表性：留出10%-20%数据做验证，覆盖实际各种场景。 灾难性遗忘：微调过度会忘掉通用能力。可在数据中混入通用数据，或使用LoRA（原始参数不动）。 过拟合：一般3-5个epoch足够，超过10个epoch基本过拟合。

面试官追问#

Q1：LoRA 的低秩分解具体怎么工作？为什么能省这么多参数？#

A：核心思路是微调过程中权重的变化量是低秩的。原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取8或16。可训练参数从 d×k 降到 d×r + r×k。例如 4096×4096 矩阵用 rank=16，参数量从1600万降到13万，压缩100多倍。推理时把 BA 加回原始权重即可，不增加延迟。

Q2：怎么判断一个任务应该用微调还是 RAG？#

A：看核心瓶颈。如果是知识不够（不知道内部文档、最新政策），用RAG更合适，知识更新方便。如果是能力不够（不会按特定格式输出、不会某种推理），用微调，RAG补不了能力短板。另外考虑实时性：RAG知识库可随时更新，微调一次成本高周期长。

Q3：微调后模型效果变差了，怎么排查？#

A：检查训练数据：有无标注错误、格式不对、数据重复。学习率是否太大：可降到原来的1/5试试。是否过拟合：训练loss降但验证loss上升，减少epoch或加dropout。是否灾难性遗忘：用原预训练模型擅长的任务测一下，若也变差说明微调数据太单一，需混入通用数据。

总结#

微调通过在预训练模型上继续训练，使模型适配垂直领域。全参数微调效果好但资源消耗大；LoRA/QLoRA 等参数高效方法大幅降低门槛，适合资源受限场景。实践中需注意数据质量、灾难性遗忘和过拟合问题。与Prompt工程、RAG结合使用可达到最佳效果。

关键点#

大模型微调 (Fine-tuning) 原理与适用场景#

大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。

本质上是在通用知识的基础上“精雕细琢”，让模型在某个垂直领域表现得更专业。
微调的核心原理是迁移学习：预训练模型已在海量数据上学会语言通用规律，微调用少量领域数据让模型学会特定表达方式和知识。
什么时候需要微调而不是直接使用基础模型？#
1. 专业领域应用：如医疗诊断、法律咨询，基础模型对专业术语掌握不够深。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Fine_Tuning_原理与场景

大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。本质上是在通用知识的基础上“精雕细琢”，让模型在某个垂直领域表现得更专业。

微调的核心原理是迁移学习：预训练模型已在海量数据上学会语言通用规律，微调用少量领域数据让模型学会特定表达方式和知识。
什么时候需要微调而不是直接使用基础模型？#
1. 专业领域应用：如医疗诊断、法律咨询，基础模型对专业术语掌握不够深。用10万条专科病历数据微调，准确率可从60%提到90%以上。
1. 数据安全要求高：金融机构、政府部门内部数据不能传到云端 API，只能把开源模型（LLaMA、Qwen）拉下来在本地机房微调部署。
本文已做格式统一与噪声清理，保留原始语义。
本质上是在通用知识的基础上“精雕细琢”，让模型在某个垂直领域表现得更专业。
微调的核心原理是迁移学习：预训练模型已在海量数据上学会语言通用规律，微调用少量领域数据让模型学会特定表达方式和知识。
什么时候需要微调而不是直接使用基础模型？#
1. 专业领域应用：如医疗诊断、法律咨询，基础模型对专业术语掌握不够深。用10万条专科病历数据微调，准确率可从60%提到90%以上。
1. 数据安全要求高：金融机构、政府部门内部数据不能传到云端 API，只能把开源模型（LLaMA、Qwen）拉下来在本地机房微调部署。
本文已做格式统一与噪声清理，保留原始语义。

GPU Concurrency Performance Analysis 整理

Wed, 10 Jun 2026 00:00:00 GMT

GPU_Concurrency_Performance_Analysis#

问题#

GPU_Concurrency_Performance_Analysis

标准回答#

GPU集群并发访问性能分析：为什么不是简单平均？#

不会简单平均成每人 1 token/s，每个用户实际看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理（Batching）把多个请求打包到一起算。GPU 擅长并行计算，100 个请求打成一个 batch，计算耗时与处理单个请求接近，吞吐量直接翻几十倍。

假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，1000 个用户分 10 批处理完，单用户实际体验的速度是 10 tokens/s。

实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

扩展知识#

1. 请求聚合与调度机制#

LLM 推理每次 forward 只生成 1 个 token，然后循环生成下一个。1000 个用户同时请求，GPU 每轮同时计算这 1000 个请求的下一个 token。需要请求聚合器协调：

把同时到达的请求按 token 长度打包，短的补齐到相同长度，打成一个矩阵扔给 GPU
设置聚合窗口（如每 5ms 或攒够 32 个请求），平衡效率与延迟
控制粒度是 token-level batching，同一时刻处理所有请求的当前 token，再一起推进

2. 动态调度与优先级#

请求进入异步队列，调度器决定处理顺序：

优先级策略：付费用户优先、重试请求优先、token 少的先算完让出位置
负载均衡：显存吃紧时减小 batch size，空闲时加大 batch
动态退场：已生成完的请求退出 batch，新请求插入，流水线持续运转

3. 实际场景分析#

聊天机器人平台：1000 用户并发，请求平均 20 tokens，GPU 最大 batch 128，吞吐 1000 tokens/s。

每 10ms 打一批，聚合 50~100 个请求
所有请求每生成一个 token 进入下一轮调度
pipeline 里同时跑多个 batch，每个 batch 装不同用户的不同 token
最终每个用户响应速度几十 token/s

4. 性能瓶颈分析思路#

显存瓶颈：KV Cache 占用大，batch size 上不去 → 看 nvidia-smi 显存占用
计算瓶颈：GPU 利用率满但吞吐低 → 模型太大或 batch 太小
调度瓶颈：队列堆积严重 → 看请求排队时间
网络瓶颈：分布式推理节点间通信慢 → 看 NCCL 耗时占比

vLLM、TensorRT-LLM 等框架提供 metrics 接口，可观察 batch size 分布、排队延迟、吞吐曲线。

面试官追问#

Q1：vLLM 的 PagedAttention 机制怎么优化显存利用率？#

A：传统做法预分配最大长度 KV Cache，浪费严重。PagedAttention 把 KV Cache 切成固定大小 block，按需分配，类似虚拟内存。显存利用率从 20~30% 提升到 90% 以上。

Q2：Continuous Batching 和 Static Batching 区别？#

A：Static Batching 等一批请求全部生成完才处理下一批，短请求需等长请求。Continuous Batching 动态调度，短请求生成完就退出，新请求立即插入，吞吐提升 2~3 倍。

Q3：First Token Latency 和 Time Per Output Token 怎么优化？#

A：First Token Latency 受 prefill 阶段影响，优化方向为 prompt 压缩、KV Cache 预计算、prefill/decode 分离。Time Per Output Token 受 decode 阶段影响，优化方向为加大 batch size、speculative decoding、量化。

Q4：模型量化对性能影响？INT8 和 FP16 怎么选？#

A：FP16 比 FP32 快一倍，INT8 再快一倍但精度可能下降。高精度场景用 FP16，极致吞吐且接受轻微效果损失用 INT8。混合精度 attention 用 FP16、FFN 用 INT8 是折中方案。AWQ、GPTQ 等方案精度损失更小。

关键点#

GPU集群并发访问性能分析：为什么不是简单平均？#
核心回答#

不会简单平均成每人 1 token/s，每个用户实际看到的响应速度可能是几十 token/s。

LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理（Batching）把多个请求打包到一起算。
GPU 擅长并行计算，100 个请求打成一个 batch，计算耗时与处理单个请求接近，吞吐量直接翻几十倍。
假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，1000 个用户分 10 批处理完，单用户实际体验的速度是 10 tokens/s。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

GPU_Concurrency_Performance_Analysis

核心回答#

假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，1000 个用户分 10 批处理完，单用户实际体验的速度是 10 tokens/s。
实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

LLM 推理每次 forward 只生成 1 个 token，然后循环生成下一个。1000 个用户同时请求，GPU 每轮同时计算这 1000 个请求的下一个 token。需要请求聚合器协调：

把同时到达的请求按 token 长度打包，短的补齐到相同长度，打成一个矩阵扔给 GPU
设置聚合窗口（如每 5ms 或攒够 32 个请求），平衡效率与延迟
控制粒度是 token-level batching，同一时刻处理所有请求的当前 token，再一起推进

请求进入异步队列，调度器决定处理顺序：

优先级策略：付费用户优先、重试请求优先、token 少的先算完让出位置
负载均衡：显存吃紧时减小 batch size，空闲时加大 batch
动态退场：已生成完的请求退出 batch，新请求插入，流水线持续运转

聊天机器人平台：1000 用户并发，请求平均 20 tokens，GPU 最大 batch 128，吞吐 1000 tokens/s。

本文已做格式统一与噪声清理，保留原始语义。
不会简单平均成每人 1 token/s，每个用户实际看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理（Batching）把多个请求打包到一起算。GPU 擅长并行计算，100 个请求打成一个 batch，计算耗时与处理单个请求接近，吞吐量直接翻几十倍。
假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，1000 个用户分 10 批处理完，单用户实际体验的速度是 10 tokens/s。
实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。
1. 请求聚合与调度机制#
LLM 推理每次 forward 只生成 1 个 token，然后循环生成下一个。1000 个用户同时请求，GPU 每轮同时计算这 1000 个请求的下一个 token。需要请求聚合器协调：
本文已做格式统一与噪声清理，保留原始语义。

LLM Long Conversation Handling 整理

Wed, 10 Jun 2026 00:00:00 GMT

LLM_Long_Conversation_Handling#

问题#

LLM_Long_Conversation_Handling

标准回答#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？#

OpenClaw 是怎么做的？

长对话的核心风险是 Context Window 溢出，导致请求报错或模型”失忆”。

OpenClaw 采用分层防御策略，从轻到重依次处理： Context Pruning（上下文修剪） 每次请求前，清理不重要的早期 Tool Result。采用两级阈值：

softTrimRatio（默认 0.3）：对超大的 tool result 做 head+tail 裁剪
hardClearRatio（默认 0.5）：直接替换为 placeholder 保护规则：保留最近 3 条 assistant 消息、第一条 user message 之前的内容（System Prompt 等）。 Tool Result Context Guard（工具返回兜底） 计算全局预算（Context Window × 4 × 0.75），先单条截断，若总量仍超则从最早的 tool result 开始替换为 [compacted: tool output removed to free context]。确保送给 LLM 的 Context 永远安全。 Memory Flush（记忆刷盘） Token 用量接近 compaction 阈值时，让 Agent 将关键信息写入 memory/YYYY-MM-DD.md，防止压缩丢失重要细节。 Compaction（压缩） 用 LLM 将旧对话历史压缩为摘要，替换原始消息。例如 100 条消息压成一段摘要，token 消耗降一个数量级。由于已做 Memory Flush，有损压缩可接受。

扩展知识#

1. Context Pruning 的巧妙保护#

基于 pi-coding-agent 的 extension，注册在 context 事件上。
可修剪的对象是早期的 tool result（默认全部可修剪，支持 allow/deny glob 配置）。
有 cache-ttl 冷却期（默认 5 分钟），避免每次请求重复扫描。

2. Tool Result 截断的智能检测#

在 tool-result-truncation.ts 中，通过 hasImportantTail() 检测尾部是否包含 error、exception、exit code、traceback 等关键词。若有则优先保留尾部（head+tail 策略），因为错误信息通常比正常输出更有价值。

3. Compaction 摘要的质量保障#

Identifier Preservation：摘要必须保留 UUID、hash、URL、文件名等不可重建的标识符。
Memory Flush 前置：在 compaction 前先落盘关键信息，降低摘要的有损风险。

面试官追问#

Q1：Compaction 压缩摘要的时机怎么选？#

A：太频繁会浪费 token 和增加延迟，太晚则 context 逼近上限。OpenClaw 采用自动触发机制：当 context token 逼近模型窗口时自动触发。在 compaction 之前，Context Pruning 已在低阈值（30% 裁剪、50% 替换）做了减负，因此 compaction 不需要太频繁。同时 Memory Flush 有独立触发条件（softThresholdTokens 默认 4000），确保关键信息提前落盘。

Q2：压缩后的摘要本身也会越来越长，怎么处理？#

A：采用滚动摘要策略。例如第一次压缩 1-50 条生成摘要 A，第二次将摘要 A + 51-100 条一起压缩成摘要 B。每次压缩保持摘要长度稳定，早期保真度虽会降低，但对多数场景 50 轮前的细节已不重要。

Q3：Context Pruning 删掉的 tool result，如果后面模型又需要了怎么办？#

A：两种恢复途径： 再次读取：如果是文件内容类（如 read_file），文件仍在磁盘，模型可再次调用工具。 Memory Flush 语义存储：在 compaction 前，LLM 自行提取关键信息（决策、配置、进度等）以语义形式写入 memory/YYYY-MM-DD.md，而非保存原始 tool result。模型后续可通过读取该文件获取上下文。

总结#

OpenClaw 的四层防御体系（修剪 → 守卫 → 刷盘 → 压缩）层层递进，既保证了长对话的持续性，又通过智能检测（错误尾部优先、标识符保留）和信息落盘，最大程度降低了有损处理带来的副作用。

关键点#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？#
OpenClaw 是怎么做的？
核心回答#

长对话的核心风险是 Context Window 溢出，导致请求报错或模型”失忆”。

OpenClaw 采用分层防御策略，从轻到重依次处理： Context Pruning（上下文修剪） 每次请求前，清理不重要的早期 Tool Result。
采用两级阈值：
softTrimRatio（默认 0.3）：对超大的 tool result 做 head+tail 裁剪
hardClearRatio（默认 0.5）：直接替换为 placeholder 保护规则：保留最近 3 条 assistant 消息、第一条 user message 之前的内容（System Prompt 等）。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

LLM_Long_Conversation_Handling

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？#

核心回答#

长对话的核心风险是 Context Window 溢出，导致请求报错或模型”失忆”。

OpenClaw 采用分层防御策略，从轻到重依次处理： Context Pruning（上下文修剪） 每次请求前，清理不重要的早期 Tool Result。采用两级阈值：
softTrimRatio（默认 0.3）：对超大的 tool result 做 head+tail 裁剪
hardClearRatio（默认 0.5）：直接替换为 placeholder 保护规则：保留最近 3 条 assistant 消息、第一条 user message 之前的内容（System Prompt 等）。
1. Tool Result Context Guard（工具返回兜底） 计算全局预算（Context Window × 4 × 0.75），先单条截断，若总量仍超则从最早的 tool result 开始替换为 [compacted: tool output removed to free context]。确保送给 LLM 的 Context 永远安全。
1. Memory Flush（记忆刷盘） Token 用量接近 compaction 阈值时，让 Agent 将关键信息写入 memory/YYYY-MM-DD.md，防止压缩丢失重要细节。
本文已做格式统一与噪声清理，保留原始语义。
OpenClaw 是怎么做的？
长对话的核心风险是 Context Window 溢出，导致请求报错或模型”失忆”。
OpenClaw 采用分层防御策略，从轻到重依次处理：
1. Context Pruning（上下文修剪）
每次请求前，清理不重要的早期 Tool Result。采用两级阈值：
本文已做格式统一与噪声清理，保留原始语义。

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？整理

Wed, 10 Jun 2026 00:00:00 GMT

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？#

问题#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？

标准回答#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？

来源: LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？.mhtml

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？#
OpenClaw 是怎么做的？
问题#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？

OpenClaw 是怎么做的？
推荐答案面试问答开始面试隐藏答案回答重点长对话最怕的就是 context window 爆了（就像手机存储满了），要么请求直接报错，要么不得不丢消息导致模型”失忆”。
本文已做格式统一与噪声清理，保留原始语义。
问题#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？

标准回答#
问题#

来源: LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？.mhtml

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？#
- OpenClaw 是怎么做的？
- 问题#

LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？

本文已做格式统一与噪声清理，保留原始语义。
LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？
LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？#
来源: LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？.mhtml
本文已做格式统一与噪声清理，保留原始语义。

关键点#

- LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？#
- OpenClaw 是怎么做的？
- 问题#
1. LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？
- OpenClaw 是怎么做的？

备注#

本文已做深度清理：移除重复内容、网页噪声、广告等，保留核心问答内容。

Memory 短期长期记忆区别存储检索整理

Wed, 10 Jun 2026 00:00:00 GMT

Memory_短期长期记忆区别存储检索#

问题#

Memory_短期长期记忆区别存储检索

标准回答#

解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？#

短期记忆：在当前会话或最近几轮对话中临时存储的信息，容量有限，生命周期短（通常一个会话）。长期记忆：跨会话持久化存储的用户偏好、事实知识或历史决策，需要主动写入和检索。

维度	短期记忆	长期记忆
生命周期	单次会话或最近N轮	跨会话持久
容量	受模型 Context Window 限制	理论无限
存储方式	内存或会话缓存	向量数据库、关系库或文件
检索方式	顺序读取或滑动窗口	语义搜索或关键词匹配
典型应用	多轮对话上下文	用户画像、知识库

存储与检索建议：

短期记忆：存储在 Redis 或内存缓存中，按会话 ID 隔离，使用 LRU 淘汰策略。检索时按时间顺序拼接进 Prompt。
长期记忆：写入向量数据库（如 Milvus、Qdrant）或关系库。检索时对用户查询做 Embedding，召回 Top-K 相关条目，再注入上下文。

扩展知识#

1. 记忆的生命周期管理#

短期→长期沉淀：通过定时任务或会话结束时，让 Agent 自动总结本次对话的关键信息，调用 memory_upsert_longterm 工具写入长期库。
记忆衰减：对长期记忆可按时间衰减权重，避免过时信息干扰（如半年前的用户偏好可能已改变）。

2. 记忆检索的时机#

主动检索：每轮对话前，用当前用户输入作为查询，去长期记忆库捞取相关条目，与短期记忆一起注入。
按需检索：只有当用户明确问“还记得我之前说过…吗”或任务明显依赖历史信息时才触发检索。

3. 常见框架的实现#

LangChain：ConversationBufferMemory（短期）+ VectorStoreRetrieverMemory（长期）。
Spring AI：可自定义 Advisor 在每次调用前加载记忆，或用 @PostConstruct 初始化记忆组件。

面试官追问#

Q1：短期记忆超出 Context Window 怎么办？#

A：采用滑动窗口，只保留最近 N 轮对话。更激进的策略是调用 LLM 对早期对话做摘要压缩（Compaction），用摘要替代原始消息。

Q2：长期记忆写入时如何避免重复或冲突？#

A：写入前先做相似度去重，若已有相似条目则合并或更新。业务上可要求用户显式确认覆盖。

Q3：如何确保 Agent 不把敏感信息写入长期记忆？#

A：在写入前加一层过滤：用规则或小模型检测密码、身份证等敏感字段，或让 Agent 在写入前询问用户“是否记住这条信息”。

总结#

短期记忆服务于当前会话的连贯性，长期记忆沉淀跨会话的价值信息。两者结合可让 Agent 既有“鱼”的短期缓存，又有“渔”的长期知识库。实现时需关注生命周期管理、检索时机与隐私安全。

关键点#

解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？#
核心回答#

短期记忆：在当前会话或最近几轮对话中临时存储的信息，容量有限，生命周期短（通常一个会话）。

长期记忆：跨会话持久化存储的用户偏好、事实知识或历史决策，需要主动写入和检索。
| 维度 | 短期记忆 | 长期记忆 | |------|----------|----------| | 生命周期 | 单次会话或最近N轮 | 跨会话持久 | | 容量 | 受模型 Context Window 限制 | 理论无限 | | 存储方式 | 内存或会话缓存 | 向量数据库、关系库或文件 | | 检索方式 | 顺序读取或滑动窗口 | 语义搜索或关键词匹配 | | 典型应用 | 多轮对话上下文 | 用户画像、知识库 |

存储与检索建议：

短期记忆：存储在 Redis 或内存缓存中，按会话 ID 隔离，使用 LRU 淘汰策略。
检索时按时间顺序拼接进 Prompt。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Memory_短期长期记忆区别存储检索

核心回答#

| 维度 | 短期记忆 | 长期记忆 | |------|----------|----------| | 生命周期 | 单次会话或最近N轮 | 跨会话持久 | | 容量 | 受模型 Context Window 限制 | 理论无限 | | 存储方式 | 内存或会话缓存 | 向量数据库、关系库或文件 | | 检索方式 | 顺序读取或滑动窗口 | 语义搜索或关键词匹配 | | 典型应用 | 多轮对话上下文 | 用户画像、知识库 |

存储与检索建议：

短期记忆：存储在 Redis 或内存缓存中，按会话 ID 隔离，使用 LRU 淘汰策略。检索时按时间顺序拼接进 Prompt。
- 长期记忆：写入向量数据库（如 Milvus、Qdrant）或关系库。检索时对用户查询做 Embedding，召回 Top-K 相关条目，再注入上下文。

短期→长期沉淀：通过定时任务或会话结束时，让 Agent 自动总结本次对话的关键信息，调用 memory_upsert_longterm 工具写入长期库。
本文已做格式统一与噪声清理，保留原始语义。
短期记忆：在当前会话或最近几轮对话中临时存储的信息，容量有限，生命周期短（通常一个会话）。长期记忆：跨会话持久化存储的用户偏好、事实知识或历史决策，需要主动写入和检索。
| 维度 | 短期记忆 | 长期记忆 |
|------|----------|----------|
| 生命周期 | 单次会话或最近N轮 | 跨会话持久 |
| 容量 | 受模型 Context Window 限制 | 理论无限 |
本文已做格式统一与噪声清理，保留原始语义。

Multi Knowledge Base RAG 整理

Wed, 10 Jun 2026 00:00:00 GMT

Multi_Knowledge_Base_RAG#

问题#

Multi_Knowledge_Base_RAG

标准回答#

你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？#

多知识库 RAG 的核心挑战是：不同知识库的数据分布、格式、质量各异，直接检索容易引入噪声或遗漏关键信息，导致效率和准确性下降，甚至产生幻觉。

解决方案：采用路由 + 融合的架构。 路由层（Router）：在检索前，先判断用户问题属于哪个知识库。可用方案：

规则路由：基于关键词匹配（如“医疗”问题路由到医疗库）。
模型路由：用小模型（如 BERT）分类问题类型。
向量路由：将用户问题 Embedding 后，与每个知识库的摘要向量比较，选择最相似的库。 检索层：在选定的知识库（或并行多个库）中执行向量检索，召回 Top-K 文档。 融合层（Fusion）：对多库召回的结果进行去重、重排序（如用 Cross-Encoder 模型），选出最相关的片段。 生成层：注入检索结果，并添加强约束 Prompt，如“如果上下文中没有明确依据，请回答‘未找到相关信息’，不要编造”。

减少幻觉的策略：

来源标注：要求模型在回答中引用具体来源（如“根据《医疗手册》第3章…”）。
自我验证：让模型先尝试回答，再用检索到的知识验证一致性。
阈值过滤：相似度低于阈值（如 0.7）的文档不送入生成阶段，直接告知用户未找到。

扩展知识#

1. 多路召回融合策略#

RRF（Reciprocal Rank Fusion）：综合多个检索结果的排名，对排名高的文档加权。
Score 归一化：不同知识库的向量距离尺度不同，需先归一化再加权平均。

2. 索引优化#

分层索引：为每个知识库单独建索引，再加一个全局摘要索引用于路由。
元数据过滤：为文档打上知识库标签，检索时通过过滤器限定范围。

3. 实践案例（医疗 + 法律双知识库）#

路由：用户问“发烧怎么办”→ 路由到医疗库；“合同纠纷”→ 路由到法律库。
融合：若问题模糊（如“责任”），并行检索两个库，用 RRF 融合结果。
幻觉防范：法律回答中强制引用法条编号；医疗回答标注“非诊疗建议”免责声明。

面试官追问#

Q1：如果路由判断错误，导致检索不到正确知识怎么办？#

A：兜底机制：当主检索结果为空或相似度过低时，自动触发一次全库检索。同时记录错误路由样本，用于定期微调路由模型。

Q2：如何评估多库 RAG 的检索效果？#

A：构建跨库测试集，对每个问题标注预期来源库和文档。评估指标：

路由准确率
召回率 Recall@K
幻觉率（人工评估或与真实知识对比）

Q3：多库 RAG 如何控制成本？#

A：① 对高频知识库做本地向量缓存；② 路由模型用小模型（如 DistilBERT）；③ 对简单问题跳过检索，直接让模型回答。

总结#

多知识库 RAG 通过路由层选择库、融合层优化结果、约束层减少幻觉，可兼顾效率与准确性。关键在于路由的准确性和融合策略的鲁棒性，同时需要完善的兜底与评估机制。

关键点#

你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？#
核心回答#

解决方案：采用路由 + 融合的架构。
1. 路由层（Router）：在检索前，先判断用户问题属于哪个知识库。
可用方案：
规则路由：基于关键词匹配（如“医疗”问题路由到医疗库）。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Multi_Knowledge_Base_RAG

核心回答#

解决方案：采用路由 + 融合的架构。
1. 路由层（Router）：在检索前，先判断用户问题属于哪个知识库。可用方案：
规则路由：基于关键词匹配（如“医疗”问题路由到医疗库）。
- 模型路由：用小模型（如 BERT）分类问题类型。
本文已做格式统一与噪声清理，保留原始语义。
多知识库 RAG 的核心挑战是：不同知识库的数据分布、格式、质量各异，直接检索容易引入噪声或遗漏关键信息，导致效率和准确性下降，甚至产生幻觉。
解决方案：采用路由 + 融合的架构。
1. 路由层（Router）：在检索前，先判断用户问题属于哪个知识库。可用方案：
- 规则路由：基于关键词匹配（如“医疗”问题路由到医疗库）。
- 模型路由：用小模型（如 BERT）分类问题类型。
本文已做格式统一与噪声清理，保留原始语义。

OpenClaw Agent Runner 工作阶段整理

Wed, 10 Jun 2026 00:00:00 GMT

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？#

核心回答#

Agent Runner 是 OpenClaw 的核心调度器（指挥中心），负责协调 LLM 调用、工具执行、错误处理等所有环节。一次完整的 Agent 运行（从用户发消息到最终输出）大致经历以下 6 个阶段：

排队
先进 session 级队列（保证同一会话串行），再进全局队列（控制总并发），防止资源被打满。
准备
解析 workspace、provider/model、thinking level 等基础参数。
插件 + Hook
加载运行时插件后，触发 before_model_resolve 和 before_agent_start 钩子。插件可以在模型解析之前动态覆盖 provider 和 model。
模型解析 + 鉴权
根据（可能被 Hook 修改过的）配置确定模型定义、上下文窗口大小，并按优先级选出可用的 API Key。
尝试执行（核心，可重试）
- 创建或恢复 Session，加载历史消息。
- 注册工具集（统一走 customTools 路径，保证沙箱和策略过滤一致性）。
- 根据 Provider 设置流式引擎（Ollama 直连、OpenAI WebSocket、通用 HTTP 等）。
- 触发执行循环：LLM 调用 → 工具执行 → 结果回传 → 再调 LLM，直到模型认为任务完成。
溢出降级
如果上下文超限：
- 先 compaction 压缩历史；
- 再截断超大 tool result；
- 都不行就报错并引导用户开新会话。

整个流程的设计思路是每个阶段都可插拔：插件通过 Hook 介入、模型和 Provider 可动态切换、工具集按需组合。

扩展知识#

1. attempt + fallback 容错机制#

Agent Runner 不是跑一次就完事，容错分两层：

Auth Profile 轮转：如果一次尝试因为 auth 失败、限流或服务过载挂了，Runner 会自动切到同 Provider 的下一个 API Key 重试。
模型级 Fallback：如果所有 Key 都轮完还是失败，Runner 向外层抛出 FailoverError，外层的 model-fallback 层会切到配置的备用模型。

重试有上限（根据 profile 数量动态计算，范围 32-160 次），不会无限重试。遇到服务过载还会加指数退避，避免继续打爆上游。

2. 工具调用的双层包装#

每个工具在注册时会经过两层包装：

Hook 拦截层：插件可以在工具执行前异步检查参数、做权限校验，甚至直接阻止执行。还内置了循环检测，防止 LLM 反复调用同一工具陷入死循环。
取消机制层：把外部的 AbortSignal 和工具自带的信号合并。当用户发了新消息、超时或手动停止时，正在执行的工具可以被中断。

3. 流式处理的 Provider 适配#

Runner 默认用通用的 streamSimple 做流式输出，但不同 Provider 的流式 API 差异很大，因此会根据 Provider 类型动态替换流式引擎：

Ollama：走原生 /api/chat 直连，绕过通用路径以获得更可靠的 streaming 和工具调用。
OpenAI：支持 WebSocket 通道，减少 HTTP 开销。
Google：额外 Gemini 特有的 thinking 字段。

所有 Provider 还会统一做工具名称规范化，确保工具分发能精确匹配。这层适配做完后，执行循环的代码不用管底下是哪家 Provider，调同一个接口即可。新增 Provider 也只需要写一个流式适配函数。

4. Context 溢出的三级降级#

执行循环中 context 可能超限，Runner 做了三级自动降级：

compaction：调用 Context Engine 压缩历史消息，腾出 token 空间。
截断超大 tool result：动态策略——先检测尾部是否包含错误信息或结果摘要；如果尾部重要则保留首尾、砍掉中间并插入省略标记，否则只保留开头。单个 tool result 最多占上下文窗口的 30%。
报错降级：前两步都救不回来时，告诉用户 context 太长了，建议开新会话。

整个过程对用户透明，尽最大努力保证对话能继续下去。

面试官追问（常见问题）#

Q1：排队执行保证并发安全，如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？
A：后面那条消息会进入 session 级队列排队等待，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。

Q2：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
A：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配（例如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同）。这些都在 session 历史清洗阶段自动处理，fallback 切换对历史消息透明，不需要手动做格式迁移。

Q3：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
A：两层包装本身的开销可以忽略不计（几个函数调用和 Promise 包装，微秒级别）。真正可能有性能影响的是 Hook 里的具体逻辑（例如某个插件在 beforeToolCall 里做了一次网络请求做权限校验），那是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。

Q4：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
A：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用“头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明，提示模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢失关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？整理

Wed, 10 Jun 2026 00:00:00 GMT

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？#

问题#

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？

标准回答#

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1144面试问答做这层抽象的根本原因是Context 管理没有万能方案。通俗理解：Context Engine 就像手机的存储管理。有的人喜欢自动清理旧照片，有的人喜欢只删大文件，有的人喜欢全部存云端按需下载。不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大。把 Context 管理抽象成接口（定义好”做什么”），让策略实现（“怎么做”）可以独立替换，既方便内部迭代，也方便社区扩展。这就是经典的策略模式。ContextEngine接口定义在src/context-engine/types.ts，覆盖了完整的生命周期：这套接口覆盖了上下文管理的完整生命周期，核心有三大操作加上若干生命周期钩子：阶段方法做什么初始化bootstrap会话首次创建时做初始化（比如导入历史）存消息ingest/ingestBatch新消息进来时怎么存、要不要做额外处理（比如向量化）挑消息assemble发给模型前，在 token 预算内挑出最合适的一组消息压消息compact历史太长时怎么压缩（摘要、裁剪、归档…）轮后处理afterTurn每轮对话结束后的收尾工作（持久化、触发后台压缩等）子 AgentprepareSubagentSpawn/onSubagentEnded管理子 Agent 的上下文隔离与回收销毁dispose释放引擎持有的资源核心调度逻辑只依赖这套接口，压根不关心背后的具体实现。通过registerContextEngine(id, factory)注册新引擎，在配置里通过plugins.slots.contextEngine一行就能切换，完全不用动核心代码。这就是典型的策略模式 + 插件化。有了这层抽象，至少能支撑以下几种完全不同的策略方向：默认的 legacy 策略：全部塞进去，塞不下了线性压缩最早的消息，简单粗暴但够用基于检索的 RAG 策略：消息入库时向量化，组装时按语义相关性捞历史，适合长对话多话题场景分层存储策略：类似冷热分离，最近几轮放内存、摘要放本地、更早的扔云端，按需拉取任务感知策略：根据当前任务类型（写代码 vs 闲聊）动态决定保留哪些历史，同样的 token 预算质量更高自定义压缩策略：通过ownsCompaction标记接管压缩，可以实现树状摘要、按话题分支压缩等高级方式

扩展知识#

内置的 legacy 引擎当前 OpenClaw 默认内置了一个legacy引擎，代码在src/context-engine/legacy.ts。它的实现非常直白：ingest是 no-op，因为消息持久化由 SessionManager 负责；assemble直接透传消息列表，不做任何筛选；compact委托给compactEmbeddedPiSessionDirect()做线性压缩。这个引擎能跑，但策略非常粗糙，基本就是”全部塞进去，塞不下了就压缩最早的”。对于简单的短对话够用，但一旦对话超过几十轮，或者涉及多个不同话题的长期交互，效果就明显不行了。可以实现的高级策略Context Engine 抽象真正的价值在于它能支撑完全不同的上下文管理思路：基于检索的 Context Engine这种引擎走 RAG 的路子。ingest的时候把每条消息向量化，存进向量库。到assemble阶段，不是按时间顺序把最近的消息拼进去，而是根据当前 query 做语义检索，把最相关的历史片段捞出来。对于那种跨好几天、中间换过好几个话题的长对话，这种方式比线性截断有效得多。分层存储引擎思路类似数据库的冷热分离。热数据就是最近 3-5 轮对话，直接放内存；温数据是最近几个 compaction 周期的摘要，放本地文件；冷数据是更早的历史，可以扔到外部存储甚至云端。assemble的时候按需从不同层拉取，既能保证最近的上下文完整，又不会因为历史太长撑爆内存。任务感知引擎根据当前任务类型动态调整 Context 组装策略。比如检测到用户在写代码，就优先保留代码相关的历史、文件路径、报错信息；检测到是闲聊，就优先保留情感偏好和个人信息。同样的 token 预算，塞进去的内容质量完全不一样。自定义 Compaction 引擎接口里有个ownsCompaction: true的标记，设了这个标记的引擎可以完全接管压缩策略。默认的线性压缩是把最早的消息一坨压成摘要，但你可以换成树状摘要，把对话按话题分支组织，每个分支独立压缩，保留更多结构化信息。插件注册机制整个切换过程对核心代码零侵入。写一个新引擎只需要实现ContextEngine接口，然后调用registerContextEngine(“my-rag-engine”, factory)注册进去。配置文件里把plugins.slots.contextEngine指向你的引擎 ID 就行了。这跟 Webpack 的 plugin 体系、VS Code 的扩展机制是一个思路，都是约定好接口，实现随便换。

面试官追问#

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？回答：legacy 引擎的消息持久化是 SessionManager 在做，ingest 啥也不干纯粹是因为职责没划到 Context Engine 这边。换成 RAG 引擎的话，ingest 就得真正接管消息的处理了，至少要做向量化和入库。迁移的关键是 SessionManager 得把”写消息”这个动作让出来，或者两边做好协调，不能重复写。实际上这也是为什么要抽象成接口的原因之一，职责边界可以随着引擎实现灵活调整。- 提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？
回答：legacy 引擎很暴力，直接从最早的消息开始砍，砍到塞得下为止。RAG 引擎好一些，它本来就是按相关性排序的，预算紧就少捞几条，质量衰减比较平滑。分层存储引擎会优先砍冷数据层，保住热数据。任务感知引擎最灵活，它可以根据任务权重动态决定哪些类型的历史先丢掉，比如写代码的时候闲聊记录优先级最低，第一个被砍。- 提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？
回答：OpenClaw 的压缩触发分两层。不设ownsCompaction的话，底层的 Pi runtime 有内置的 auto-compaction，它自己监控 token 用量，超过阈值就自动压缩，外层 Runner 不需要手动介入。设了ownsCompaction: true之后，Pi 的内置 auto-compaction 会被禁用，改由引擎自己通过afterTurn等生命周期钩子决定什么时候压、怎么压。但不管设没设这个标记，Runner 还有一层溢出压缩兜底，当上下文真的塞不下时，Runner 会直接调contextEngine.compact()做紧急压缩。简单说就是：ownsCompaction控制的是”日常谁来管压缩”，但”快炸了”的时候 Runner 一定会兜底。这种设计对有自己一套存储和索引体系的引擎特别重要，因为通用的压缩逻辑不了解引擎内部的数据组织方式，日常由引擎自主管理更合理。作者：Yes面试鸭官方不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大

把 Context 管理抽象成接口，让策略实现可以独立替换，方便内部迭代，也方便社区扩展。

有了这层抽象，能支持以下几种完全不同的策略方向：

1.展开新页面打开2026-03-17 22:2900回复晚夜微雨问海棠特训营一、OpenClaw 抽象 Context Engine 的核心原因OpenClaw 将上下文管理从硬编码逻辑升级为可插拔的 Context Engine 插件化架构，本质是软件架构设计中「关注点分离（Separation of Concerns）」与「策略模式（Strat展开新页面打开2026-03-15 10:2600回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本**斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

内置的 legacy 引擎可以实现的高级策略插件注册机制

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:28在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？如果一个 Agent 系统要同时接入 Telegram、飞书、钉钉等渠道，你会怎么设计抽象层？OpenClaw 的 Channel Plugin 接口是怎么设计的？13232. OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1144面试问答做这层抽象的根本原因是Context 管理没有万能方案。通俗理解：Context Engine 就像手机的存储管理。有的人喜欢自动清理旧照片，有的人喜欢只删大文件，有的人喜欢全部存云端按需下载。不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大。把 Context 管理抽象成接口（定义好”做什么”），让策略实现（“怎么做”）可以独立替换，既方便内部迭代，也方便社区扩展。这就是经典的策略模式。ContextEngine接口定义在src/context-engine/types.ts，覆盖了完整的生命周期：这套接口覆盖了上下文管理的完整生命周期，核心有三大操作加上若干生命周期钩子：阶段方法做什么初始化bootstrap会话首次创建时做初始化（比如导入历史）存消息ingest/ingestBatch新消息进来时怎么存、要不要做额外处理（比如向量化）挑消息assemble发给模型前，在 token 预算内挑出最合适的一组消息压消息compact历史太长时怎么压缩（摘要、裁剪、归档…）轮后处理afterTurn每轮对话结束后的收尾工作（持久化、触发后台压缩等）子 AgentprepareSubagentSpawn/onSubagentEnded管理子 Agent 的上下文隔离与回收销毁dispose释放引擎持有的资源核心调度逻辑只依赖这套接口，压根不关心背后的具体实现。通过registerContextEngine(id, factory)注册新引擎，在配置里通过plugins.slots.contextEngine一行就能切换，完全不用动核心代码。这就是典型的策略模式 + 插件化。有了这层抽象，至少能支撑以下几种完全不同的策略方向：默认的 legacy 策略：全部塞进去，塞不下了线性压缩最早的消息，简单粗暴但够用基于检索的 RAG 策略：消息入库时向量化，组装时按语义相关性捞历史，适合长对话多话题场景分层存储策略：类似冷热分离，最近几轮放内存、摘要放本地、更早的扔云端，按需拉取任务感知策略：根据当前任务类型（写代码 vs 闲聊）动态决定保留哪些历史，同样的 token 预算质量更高自定义压缩策略：通过ownsCompaction标记接管压缩，可以实现树状摘要、按话题分支压缩等高级方式

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？回答：legacy 引擎的消息持久化是 SessionManager 在做，ingest 啥也不干纯粹是因为职责没划到 Context Engine 这边。换成 RAG 引擎的话，ingest 就得真正接管消息的处理了，至少要做向量化和入库。迁移的关键是 SessionManager 得把”写消息”这个动作让出来，或者两边做好协调，不能重复写。实际上这也是为什么要抽象成接口的原因之一，职责边界可以随着引擎实现灵活调整。- 提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？
回答：legacy 引擎很暴力，直接从最早的消息开始砍，砍到塞得下为止。RAG 引擎好一些，它本来就是按相关性排序的，预算紧就少捞几条，质量衰减比较平滑。分层存储引擎会优先砍冷数据层，保住热数据。任务感知引擎最灵活，它可以根据任务权重动态决定哪些类型的历史先丢掉，比如写代码的时候闲聊记录优先级最低，第一个被砍。- 提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？
回答：OpenClaw 的压缩触发分两层。不设ownsCompaction的话，底层的 Pi runtime 有内置的 auto-compaction，它自己监控 token 用量，超过阈值就自动压缩，外层 Runner 不需要手动介入。设了ownsCompaction: true之后，Pi 的内置 auto-compaction 会被禁用，改由引擎自己通过afterTurn等生命周期钩子决定什么时候压、怎么压。但不管设没设这个标记，Runner 还有一层溢出压缩兜底，当上下文真的塞不下时，Runner 会直接调contextEngine.compact()做紧急压缩。简单说就是：ownsCompaction控制的是”日常谁来管压缩”，但”快炸了”的时候 Runner 一定会兜底。这种设计对有自己一套存储和索引体系的引擎特别重要，因为通用的压缩逻辑不了解引擎内部的数据组织方式，日常由引擎自主管理更合理。作者：Yes面试鸭官方不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大

把 Context 管理抽象成接口，让策略实现可以独立替换，方便内部迭代，也方便社区扩展。

有了这层抽象，能支持以下几种完全不同的策略方向：

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

内置的 legacy 引擎可以实现的高级策略插件注册机制

来源: OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？.mhtml

关键点#

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？#
这个设计能支持哪些不同的策略？
问题#

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？

这个设计能支持哪些不同的策略？
NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1144面试问答做这层抽象的根本原因是Context 管理没有万能方案。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？

标准回答#
问题#

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？回答：legacy 引擎的消息持久化是 SessionManager 在做，ingest 啥也不干纯粹是因为职责没划到 Context Engine 这边。换成 RAG 引擎的话，ingest 就得真正接管消息的处理了，至少要做向量化和入库。迁移的关键是 SessionManager 得把”写消息”这个动作让出来，或者两边做好协调，不能重复写。实际上这也是为什么要抽象成接口的原因之一，职责边界可以随着引擎实现灵活调整。- 提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？
回答：legacy 引擎很暴力，直接从最早的消息开始砍，砍到塞得下为止。RAG 引擎好一些，它本来就是按相关性排序的，预算紧就少捞几条，质量衰减比较平滑。分层存储引擎会优先砍冷数据层，保住热数据。任务感知引擎最灵活，它可以根据任务权重动态决定哪些类型的历史先丢掉，比如写代码的时候闲聊记录优先级最低，第一个被砍。- 提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？
回答：OpenClaw 的压缩触发分两层。不设ownsCompaction的话，底层的 Pi runtime 有内置的 auto-compaction，它自己监控 token 用量，超过阈值就自动压缩，外层 Runner 不需要手动介入。设了ownsCompaction: true之后，Pi 的内置 auto-compaction 会被禁用，改由引擎自己通过afterTurn等生命周期钩子决定什么时候压、怎么压。但不管设没设这个标记，Runner 还有一层溢出压缩兜底，当上下文真的塞不下时，Runner 会直接调contextEngine.compact()做紧急压缩。简单说就是：ownsCompaction控制的是”日常谁来管压缩”，但”快炸了”的时候 Runner 一定会兜底。这种设计对有自己一套存储和索引体系的引擎特别重要，因为通用的压缩逻辑不了解引擎内部的数据组织方式，日常由引擎自主管理更合理。作者：Yes面试鸭官方不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大

把 Context 管理抽象成接口，让策略实现可以独立替换，方便内部迭代，也方便社区扩展。

有了这层抽象，能支持以下几种完全不同的策略方向：

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

内置的 legacy 引擎可以实现的高级策略插件注册机制

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？回答：legacy 引擎的消息持久化是 SessionManager 在做，ingest 啥也不干纯粹是因为职责没划到 Context Engine 这边。换成 RAG 引擎的话，ingest 就得真正接管消息的处理了，至少要做向量化和入库。迁移的关键是 SessionManager 得把”写消息”这个动作让出来，或者两边做好协调，不能重复写。实际上这也是为什么要抽象成接口的原因之一，职责边界可以随着引擎实现灵活调整。- 提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？
回答：legacy 引擎很暴力，直接从最早的消息开始砍，砍到塞得下为止。RAG 引擎好一些，它本来就是按相关性排序的，预算紧就少捞几条，质量衰减比较平滑。分层存储引擎会优先砍冷数据层，保住热数据。任务感知引擎最灵活，它可以根据任务权重动态决定哪些类型的历史先丢掉，比如写代码的时候闲聊记录优先级最低，第一个被砍。- 提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？
回答：OpenClaw 的压缩触发分两层。不设ownsCompaction的话，底层的 Pi runtime 有内置的 auto-compaction，它自己监控 token 用量，超过阈值就自动压缩，外层 Runner 不需要手动介入。设了ownsCompaction: true之后，Pi 的内置 auto-compaction 会被禁用，改由引擎自己通过afterTurn等生命周期钩子决定什么时候压、怎么压。但不管设没设这个标记，Runner 还有一层溢出压缩兜底，当上下文真的塞不下时，Runner 会直接调contextEngine.compact()做紧急压缩。简单说就是：ownsCompaction控制的是”日常谁来管压缩”，但”快炸了”的时候 Runner 一定会兜底。这种设计对有自己一套存储和索引体系的引擎特别重要，因为通用的压缩逻辑不了解引擎内部的数据组织方式，日常由引擎自主管理更合理。作者：Yes面试鸭官方不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大

把 Context 管理抽象成接口，让策略实现可以独立替换，方便内部迭代，也方便社区扩展。

有了这层抽象，能支持以下几种完全不同的策略方向：

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

内置的 legacy 引擎可以实现的高级策略插件注册机制

来源: OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？.mhtml

OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？#
本文已做格式统一与噪声清理，保留原始语义。
OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？
OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？#
1. OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1144面试问答做这层抽象的根本原因是Context 管理没有万能方案。通俗理解：Context Engine 就像手机的存储管理。有的人喜欢自动清理旧照片，有的人喜欢只删大文件，有的人喜欢全部存云端按需下载。不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大。把 Context 管理抽象成接口（定义好”做什么”），让策略实现（“怎么做”）可以独立替换，既方便内部迭代，也方便社区扩展。这就是经典的策略模式。ContextEngine接口定义在src/context-engine/types.ts，覆盖了完整的生命周期：这套接口覆盖了上下文管理的完整生命周期，核心有三大操作加上若干生命周期钩子：阶段方法做什么初始化bootstrap会话首次创建时做初始化（比如导入历史）存消息ingest/ingestBatch新消息进来时怎么存、要不要做额外处理（比如向量化）挑消息assemble发给模型前，在 token 预算内挑出最合适的一组消息压消息compact历史太长时怎么压缩（摘要、裁剪、归档…）轮后处理afterTurn每轮对话结束后的收尾工作（持久化、触发后台压缩等）子 AgentprepareSubagentSpawn/onSubagentEnded管理子 Agent 的上下文隔离与回收销毁dispose释放引擎持有的资源核心调度逻辑只依赖这套接口，压根不关心背后的具体实现。通过registerContextEngine(id, factory)注册新引擎，在配置里通过plugins.slots.contextEngine一行就能切换，完全不用动核心代码。这就是典型的策略模式 + 插件化。有了这层抽象，至少能支撑以下几种完全不同的策略方向：默认的 legacy 策略：全部塞进去，塞不下了线性压缩最早的消息，简单粗暴但够用基于检索的 RAG 策略：消息入库时向量化，组装时按语义相关性捞历史，适合长对话多话题场景分层存储策略：类似冷热分离，最近几轮放内存、摘要放本地、更早的扔云端，按需拉取任务感知策略：根据当前任务类型（写代码 vs 闲聊）动态决定保留哪些历史，同样的 token 预算质量更高自定义压缩策略：通过ownsCompaction标记接管压缩，可以实现树状摘要、按话题分支压缩等高级方式

提问：legacy 引擎的 ingest 是 no-op，那消息是谁在管？如果换成 RAG 引擎，这块职责怎么迁移？回答：legacy 引擎的消息持久化是 SessionManager 在做，ingest 啥也不干纯粹是因为职责没划到 Context Engine 这边。换成 RAG 引擎的话，ingest 就得真正接管消息的处理了，至少要做向量化和入库。迁移的关键是 SessionManager 得把”写消息”这个动作让出来，或者两边做好协调，不能重复写。实际上这也是为什么要抽象成接口的原因之一，职责边界可以随着引擎实现灵活调整。- 提问：assemble 的时候有个 token 预算参数，如果预算给得很紧，不同引擎的降级策略会有什么差异？
回答：legacy 引擎很暴力，直接从最早的消息开始砍，砍到塞得下为止。RAG 引擎好一些，它本来就是按相关性排序的，预算紧就少捞几条，质量衰减比较平滑。分层存储引擎会优先砍冷数据层，保住热数据。任务感知引擎最灵活，它可以根据任务权重动态决定哪些类型的历史先丢掉，比如写代码的时候闲聊记录优先级最低，第一个被砍。- 提问：ownsCompaction 这个标记具体怎么生效的？不设这个标记的话压缩是谁触发的？
回答：OpenClaw 的压缩触发分两层。不设ownsCompaction的话，底层的 Pi runtime 有内置的 auto-compaction，它自己监控 token 用量，超过阈值就自动压缩，外层 Runner 不需要手动介入。设了ownsCompaction: true之后，Pi 的内置 auto-compaction 会被禁用，改由引擎自己通过afterTurn等生命周期钩子决定什么时候压、怎么压。但不管设没设这个标记，Runner 还有一层溢出压缩兜底，当上下文真的塞不下时，Runner 会直接调contextEngine.compact()做紧急压缩。简单说就是：ownsCompaction控制的是”日常谁来管压缩”，但”快炸了”的时候 Runner 一定会兜底。这种设计对有自己一套存储和索引体系的引擎特别重要，因为通用的压缩逻辑不了解引擎内部的数据组织方式，日常由引擎自主管理更合理。作者：Yes面试鸭官方- 不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大
把 Context 管理抽象成接口，让策略实现可以独立替换，方便内部迭代，也方便社区扩展。
本文已做格式统一与噪声清理，保留原始语义。

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？整理

Wed, 10 Jun 2026 00:00:00 GMT

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？#

问题#

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？

标准回答#

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？NEW困难AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1200面试问答Agent Runner 是 OpenClaw 的核心调度器，可以理解为”指挥中心”，负责协调 LLM 调用、工具执行、错误处理等所有环节。一次完整的 Agent 运行从用户发消息到最终输出，大致经历以下阶段：1）排队，先进 session 级队列（保证同一会话串行），再进全局队列（控制总并发），防止资源被打满2）准备，解析 workspace、provider/model、thinking level 等基础参数3）插件 + Hook，加载运行时插件后，触发before_model_resolve和before_agent_start钩子，插件可以在模型解析之前动态覆盖 provider 和 model4）模型解析 + 鉴权，根据（可能被 Hook 修改过的）配置确定模型定义、上下文窗口大小，并按优先级选出可用的 API Key5）尝试执行（核心，可重试）：创建或恢复 Session，加载历史消息注册工具集（统一走 customTools 路径，保证沙箱和策略过滤一致性）根据 Provider 设置流式引擎（Ollama 直连、OpenAI WebSocket、通用 HTTP 等）触发执行循环：LLM 调用 → 工具执行 → 结果回传 → 再调 LLM，直到模型认为任务完成6）溢出降级，如果上下文超限：先 compaction 压缩历史 → 再截断超大 tool result → 都不行就报错引导用户开新会话整个流程的设计思路是每个阶段都可插拔。插件通过 Hook 介入、模型和 Provider 可动态切换、工具集按需组合。

扩展知识#

attempt + fallback 容错机制Agent Runner 不是跑一次就完事，容错分两层：1）Auth Profile 轮转：如果一次尝试因为 auth 失败、限流或服务过载挂了，Runner 会自动切到同 Provider 的下一个 API Key 重试。比如配了三个 OpenAI Key，第一个被限流就自动换第二个。

2）模型级 Fallback：如果所有 Key 都轮完还是失败，Runner 向外层抛出 FailoverError，外层的 model-fallback 层会切到配置的备用模型。比如 Claude 整体不可用就降级到 GPT-4o，用户几乎感知不到切换。重试有上限（根据 profile 数量动态计算，范围 32-160 次），不会无限重试。遇到服务过载还会加指数退避，避免继续打爆上游。工具调用的双层包装每个工具在注册时会经过两层包装：1）Hook 拦截层：插件可以在工具执行前异步检查参数、做权限校验，甚至直接阻止执行。这一层还内置了循环检测，防止 LLM 反复调用同一工具陷入死循环。

2）取消机制层：把外部的 AbortSignal 和工具自带的信号合并。当用户发了新消息、超时了、或手动停止时，正在执行的工具可以被中断，不用干等到超时。流式处理的 Provider 适配Runner 默认用通用的streamSimple做流式输出，但不同 Provider 的流式 API 差异很大，所以会根据 Provider 类型动态替换流式引擎：Ollama：走原生/api/chat直连，绕过通用路径以获得更可靠的 streaming 和工具调用OpenAI：支持 WebSocket 通道，减少 HTTP 开销Google：额外 Gemini 特有的 thinking 字段所有 Provider 还会统一做工具名称规范化（有些模型输出的工具名带空格或前缀），确保工具分发能精确匹配这层适配做完后，执行循环的代码不用管底下是哪家 Provider，调同一个接口就行。新增 Provider 也只需要写一个流式适配函数。Context 溢出的三级降级执行循环跑着跑着 context 可能会超限，特别是工具返回了大量内容的时候。Runner 对此做了三级自动降级：1）先尝试compaction，调用 Context Engine 压缩历史消息，腾出 token 空间2）compaction 还不够的话，截断超大 tool result。截断策略是动态的：先检测尾部是否包含错误信息或结果摘要，如果尾部重要就保留首尾、砍掉中间；否则只保留开头。截断位置会插入说明提示模型内容被截断了。单个 tool result 最多占上下文窗口的 30%3）前两步都救不回来，报错降级，告诉用户 context 太长了，建议开新会话整个过程对用户透明，尽最大努力保证对话能继续下去。

面试官追问#

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方一次完整的 Agent 运行，大致分一下几个阶段：排队：先进 session级队列后进全局队列准备：解析 workspace、provider/model、thin展开新页面打开2026-03-15 19:2000回复晚夜微雨问海棠特训营一、OpenClaw 工具执行模块的稳定性保障体系OpenClaw 的工具执行模块（Tools System/Skill Execution Engine）是打通AI「思考」到「落地」的核心执行单元，其稳定性通过多层级、全链路的防护与容错机制实现，从执行前、执行中、执行后全周期覆盖，核展开新页面打开2026-03-15 09:1500回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

attempt + fallback 容错机制工具调用的双层包装流式处理的 Provider 适配Context 溢出的三级降级

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:28在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？如果一个 Agent 系统要同时接入 Telegram、飞书、钉钉等渠道，你会怎么设计抽象层？OpenClaw 的 Channel Plugin 接口是怎么设计的？13228. OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？NEW困难AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1200面试问答Agent Runner 是 OpenClaw 的核心调度器，可以理解为”指挥中心”，负责协调 LLM 调用、工具执行、错误处理等所有环节。一次完整的 Agent 运行从用户发消息到最终输出，大致经历以下阶段：1）排队，先进 session 级队列（保证同一会话串行），再进全局队列（控制总并发），防止资源被打满2）准备，解析 workspace、provider/model、thinking level 等基础参数3）插件 + Hook，加载运行时插件后，触发before_model_resolve和before_agent_start钩子，插件可以在模型解析之前动态覆盖 provider 和 model4）模型解析 + 鉴权，根据（可能被 Hook 修改过的）配置确定模型定义、上下文窗口大小，并按优先级选出可用的 API Key5）尝试执行（核心，可重试）：创建或恢复 Session，加载历史消息注册工具集（统一走 customTools 路径，保证沙箱和策略过滤一致性）根据 Provider 设置流式引擎（Ollama 直连、OpenAI WebSocket、通用 HTTP 等）触发执行循环：LLM 调用 → 工具执行 → 结果回传 → 再调 LLM，直到模型认为任务完成6）溢出降级，如果上下文超限：先 compaction 压缩历史 → 再截断超大 tool result → 都不行就报错引导用户开新会话整个流程的设计思路是每个阶段都可插拔。插件通过 Hook 介入、模型和 Provider 可动态切换、工具集按需组合。

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方一次完整的 Agent 运行，大致分一下几个阶段：排队：先进 session级队列后进全局队列准备：解析 workspace、provider/model、thin展开新页面打开2026-03-15 19:2000回复晚夜微雨问海棠特训营一、OpenClaw 工具执行模块的稳定性保障体系OpenClaw 的工具执行模块（Tools System/Skill Execution Engine）是打通AI「思考」到「落地」的核心执行单元，其稳定性通过多层级、全链路的防护与容错机制实现，从执行前、执行中、执行后全周期覆盖，核展开新页面打开2026-03-15 09:1500回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

attempt + fallback 容错机制工具调用的双层包装流式处理的 Provider 适配Context 溢出的三级降级

来源: OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？.mhtml

关键点#

OpenClaw 的 Agent Runner 是如何工作的？#
一次 Agent 运行经历了哪些阶段？
问题#

OpenClaw 的 Agent Runner 是如何工作的？

一次 Agent 运行经历了哪些阶段？
NEW困难AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1200面试问答Agent Runner 是 OpenClaw 的核心调度器，可以理解为”指挥中心”，负责协调 LLM 调用、工具执行、错误处理等所有环节。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？

标准回答#
问题#

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方一次完整的 Agent 运行，大致分一下几个阶段：排队：先进 session级队列后进全局队列准备：解析 workspace、provider/model、thin展开新页面打开2026-03-15 19:2000回复晚夜微雨问海棠特训营一、OpenClaw 工具执行模块的稳定性保障体系OpenClaw 的工具执行模块（Tools System/Skill Execution Engine）是打通AI「思考」到「落地」的核心执行单元，其稳定性通过多层级、全链路的防护与容错机制实现，从执行前、执行中、执行后全周期覆盖，核展开新页面打开2026-03-15 09:1500回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

attempt + fallback 容错机制工具调用的双层包装流式处理的 Provider 适配Context 溢出的三级降级

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方一次完整的 Agent 运行，大致分一下几个阶段：排队：先进 session级队列后进全局队列准备：解析 workspace、provider/model、thin展开新页面打开2026-03-15 19:2000回复晚夜微雨问海棠特训营一、OpenClaw 工具执行模块的稳定性保障体系OpenClaw 的工具执行模块（Tools System/Skill Execution Engine）是打通AI「思考」到「落地」的核心执行单元，其稳定性通过多层级、全链路的防护与容错机制实现，从执行前、执行中、执行后全周期覆盖，核展开新页面打开2026-03-15 09:1500回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

attempt + fallback 容错机制工具调用的双层包装流式处理的 Provider 适配Context 溢出的三级降级

来源: OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？.mhtml

OpenClaw 的 Agent Runner 是如何工作的？#
- 一次 Agent 运行经历了哪些阶段？
- 问题#

OpenClaw 的 Agent Runner 是如何工作的？

本文已做格式统一与噪声清理，保留原始语义。
OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？
OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？#
1. OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？NEW困难AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1200面试问答Agent Runner 是 OpenClaw 的核心调度器，可以理解为”指挥中心”，负责协调 LLM 调用、工具执行、错误处理等所有环节。一次完整的 Agent 运行从用户发消息到最终输出，大致经历以下阶段：1）排队，先进 session 级队列（保证同一会话串行），再进全局队列（控制总并发），防止资源被打满2）准备，解析 workspace、provider/model、thinking level 等基础参数3）插件 + Hook，加载运行时插件后，触发before_model_resolve和before_agent_start钩子，插件可以在模型解析之前动态覆盖 provider 和 model4）模型解析 + 鉴权，根据（可能被 Hook 修改过的）配置确定模型定义、上下文窗口大小，并按优先级选出可用的 API Key5）尝试执行（核心，可重试）：创建或恢复 Session，加载历史消息注册工具集（统一走 customTools 路径，保证沙箱和策略过滤一致性）根据 Provider 设置流式引擎（Ollama 直连、OpenAI WebSocket、通用 HTTP 等）触发执行循环：LLM 调用 → 工具执行 → 结果回传 → 再调 LLM，直到模型认为任务完成6）溢出降级，如果上下文超限：先 compaction 压缩历史 → 再截断超大 tool result → 都不行就报错引导用户开新会话整个流程的设计思路是每个阶段都可插拔。插件通过 Hook 介入、模型和 Provider 可动态切换、工具集按需组合。

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方- 一次完整的 Agent 运行，大致分一下几个阶段：排队：先进 session级队列后进全局队列准备：解析 workspace、provider/model、thin展开新页面打开2026-03-15 19:2000回复晚夜微雨问海棠特训营一、OpenClaw 工具执行模块的稳定性保障体系OpenClaw 的工具执行模块（Tools System/Skill Execution Engine）是打通AI「思考」到「落地」的核心执行单元，其稳定性通过多层级、全链路的防护与容错机制实现，从执行前、执行中、执行后全周期覆盖，核展开新页面打开2026-03-15 09:1500回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

attempt + fallback 容错机制工具调用的双层包装流式处理的 Provider 适配Context 溢出的三级降级

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:28在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？如果一个 Agent 系统要同时接入 Telegram、飞书、钉钉等渠道，你会怎么设计抽象层？OpenClaw 的 Channel Plugin 接口是怎么设计的？13228. OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？NEW困难AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1200面试问答Agent Runner 是 OpenClaw 的核心调度器，可以理解为”指挥中心”，负责协调 LLM 调用、工具执行、错误处理等所有环节。一次完整的 Agent 运行从用户发消息到最终输出，大致经历以下阶段：1）排队，先进 session 级队列（保证同一会话串行），再进全局队列（控制总并发），防止资源被打满2）准备，解析 workspace、provider/model、thinking level 等基础参数3）插件 + Hook，加载运行时插件后，触发before_model_resolve和before_agent_start钩子，插件可以在模型解析之前动态覆盖 provider 和 model4）模型解析 + 鉴权，根据（可能被 Hook 修改过的）配置确定模型定义、上下文窗口大小，并按优先级选出可用的 API Key5）尝试执行（核心，可重试）：创建或恢复 Session，加载历史消息注册工具集（统一走 customTools 路径，保证沙箱和策略过滤一致性）根据 Provider 设置流式引擎（Ollama 直连、OpenAI WebSocket、通用 HTTP 等）触发执行循环：LLM 调用 → 工具执行 → 结果回传 → 再调 LLM，直到模型认为任务完成6）溢出降级，如果上下文超限：先 compaction 压缩历史 → 再截断超大 tool result → 都不行就报错引导用户开新会话整个流程的设计思路是每个阶段都可插拔。插件通过 Hook 介入、模型和 Provider 可动态切换、工具集按需组合。

提问：你说排队执行保证并发安全，那如果用户快速连发两条消息会怎样？后面那条是排队等还是直接丢弃？回答：后面那条消息会进入 session 级队列排队等，不会丢弃也不会并发执行。设计上是嵌套两级队列：先进 session 队列（保证同 session 串行），再进全局队列（控制总并发）。等前一条消息的 Agent 运行完成后才处理下一条。用户体验上是第二条消息会等一会儿才开始响应。- 提问：fallback 机制切换模型之后，之前的对话历史格式兼容吗？不同模型的消息格式不一样怎么办？
回答：历史消息以统一的中间格式存储在 session 文件中。切换模型时用的是同一份 session file，新的 attempt 启动时会根据目标 Provider 的特性做格式适配。比如 Gemini 和 Anthropic 的 turn 交替规则不同、thinking block 处理不同，这些都在 session 历史清洗阶段自动处理。所以 fallback 切换对历史消息是透明的，不需要手动做格式迁移。- 提问：工具的 Hook 拦截层会不会引入性能问题？每次工具调用都多走两层包装，延迟能接受吗？
回答：两层包装本身的开销可以忽略不计，就是几个函数调用和 Promise 包装，微秒级别。真正可能有性能影响的是 Hook 里的具体逻辑，比如某个插件在 beforeToolCall 里做了一次网络请求做权限校验，那这个延迟是插件自己的问题，不是框架的问题。没注册 Hook 的话，拦截层会直接透传到原始工具函数，几乎零开销。- 提问：Context 溢出的时候截断 tool result，截断策略是什么？会不会截掉关键信息？
回答：截断策略是动态的。它会先检测 tool result 尾部是否包含错误信息、结果摘要或 JSON 闭合结构。如果尾部重要，采用”头+尾”策略保留首尾、砍掉中间并插入省略标记；如果尾部不重要，只保留头部。截断后会追加说明告诉模型内容被截断了，模型可以决定是否需要重新调用工具分段读取。当然会有丢关键信息的风险，这是工程上的折中，总比直接报错中断对话要好。作者：Yes面试鸭官方
本文已做格式统一与噪声清理，保留原始语义。

Re Reading SpringAI 实现整理

Wed, 10 Jun 2026 00:00:00 GMT

Re_Reading_SpringAI_实现#

问题#

Re_Reading_SpringAI_实现

标准回答#

什么是 Re-Reading？#

如何基于 Spring AI 实现 Re-Reading Advisor？

Re-Reading（重读），也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。核心思想是：对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答。有文献研究证明这是有一定效果的。

注意：这种方法会因重复处理输入导致成本加倍，在面向 C 端开放的应用中需谨慎使用。

基于 Spring AI 的实现步骤： 创建自定义 Advisor 类：该类需同时实现 CallAroundAdvisor（同步请求）和 StreamAroundAdvisor（流式请求）接口，让该类更通用。 （在 Spring AI 1.0 版本中，上述两个接口需改为 CallAdvisor 和 StreamAdvisor） 修改用户提示词：在 Advisor 的前置处理逻辑中（如 aroundCall 或 aroundStream 方法调用之前），对用户的原始输入文本进行改写。改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读。通过看源码能够看到提示词格式：

1
{Input_Query}
2
Read the question again: {Input_Query}

其中 {Input_Query} 是用户原始的提问内容。 传递给模型：将改写后的提示词传递给大语言模型进行处理。

扩展知识#

1. Re-Reading 的适用场景#

复杂推理题：数学、逻辑、多步骤任务
长指令遵循：包含多个约束条件的任务
易产生歧义的问题：通过重读可消除理解偏差

2. 成本与收益权衡#

成本：每次请求 token 消耗翻倍（输入翻倍，输出不变）
收益：准确率提升 5-15%（取决于模型和任务复杂度）
决策：对高价值任务（如医疗、金融）可接受；对高并发 C 端场景需谨慎

3. 与类似技术的对比#

技术	原理	成本	适用场景
Re-Reading	重复输入 + 明确指令	token ×2	复杂推理
Chain-of-Thought	中间推理步骤	输出长	数学/逻辑题
Self-Consistency	多次采样投票	token ×N	高准确率要求
ReAct	推理+行动循环	多次 LLM 调用	Agent 任务

面试官追问#

Q1：Re-Reading 和简单的“再说一遍”有什么区别？#

A：Re-Reading 不是让用户重复输入，而是在系统层面用明确指令（如“Read the question again:”）引导模型重新审视问题。这种结构化重复比自然语言重复更有效，且可封装为 Advisor 自动应用。

Q2：如果模型本身足够强大（如 GPT-4），Re-Reading 还有用吗？#

A：有用，但提升幅度较小。研究表明，对复杂推理任务，即使 SOTA 模型也能从 Re-Reading 中获益（3-8% 准确率提升）。对小模型（7B-13B）效果更显著。

Q3：如何避免 Re-Reading 带来的重复计费问题？#

A：

选择性启用：仅对高复杂度任务启用（如通过分类器判断是否需要）
Prompt 缓存：利用 LLM 提供商的 prompt 缓存功能（如 Anthropic、DeepSeek），相同前缀可降低成本
模型筛选：对简单的日常问答跳过 Re-Reading

Q4：Spring AI 的 Advisor 链中，Re-Reading Advisor 应该放在什么位置？#

A：建议放在早期，在参数验证、日志等基础 Advisor 之后，但在 RAG 检索、工具调用等业务 Advisor 之前。因为 Re-Reading 仅修改用户输入，不依赖外部数据，提前处理可让后续 Advisor 基于增强后的输入工作。

总结#

Re-Reading 是一种简单有效的提示工程技巧，通过结构化重复输入提升模型推理准确率。在 Spring AI 中，实现自定义 Advisor 即可无缝集成。需根据任务复杂度和成本敏感性决定是否启用。

关键点#

什么是 Re-Reading？#
如何基于 Spring AI 实现 Re-Reading Advisor？
核心回答#

Re-Reading（重读），也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。

核心思想是：对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答。
有文献研究证明这是有一定效果的。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Re_Reading_SpringAI_实现

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？#

核心回答#

注意：这种方法会因重复处理输入导致成本加倍，在面向 C 端开放的应用中需谨慎使用。
基于 Spring AI 的实现步骤： 创建自定义 Advisor 类：该类需同时实现 CallAroundAdvisor（同步请求）和 StreamAroundAdvisor（流式请求）接口，让该类更通用。
（在 Spring AI 1.0 版本中，上述两个接口需改为 CallAdvisor 和 StreamAdvisor） 修改用户提示词：在 Advisor 的前置处理逻辑中（如 aroundCall 或 aroundStream 方法调用之前），对用户的原始输入文本进行改写。改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读。通过看源码能够看到提示词格式：

1
{Input_Query}
2
Read the question again: {Input_Query}

其中 {Input_Query} 是用户原始的提问内容。

本文已做格式统一与噪声清理，保留原始语义。
如何基于 Spring AI 实现 Re-Reading Advisor？
Re-Reading（重读），也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。核心思想是：对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答。有文献研究证明这是有一定效果的。
注意：这种方法会因重复处理输入导致成本加倍，在面向 C 端开放的应用中需谨慎使用。
基于 Spring AI 的实现步骤：
1. 创建自定义 Advisor 类：该类需同时实现 CallAroundAdvisor（同步请求）和 StreamAroundAdvisor（流式请求）接口，让该类更通用。
本文已做格式统一与噪声清理，保留原始语义。

React Form Prompt Design 整理

Wed, 10 Jun 2026 00:00:00 GMT

React_Form_Prompt_Design#

问题#

React_Form_Prompt_Design

标准回答#

设计包含上下文约束的 React 表单组件 Prompt#

要让大模型生成能直接使用的 React 表单组件，Prompt 必须覆盖四个维度：字段定义、验证规？、交互行为、代码规范。以下是一个实战级 Prompt 模板：

1
用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
2

3
字段清单：
4
- 用户名：必填，2-10 个字符，只能包含字母数字下划线
5
- 邮箱：必填，标准邮箱格式
6
- 密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
7
- 确认密码：必填，必须和密码字段一致
8
- 手机号：选填，11 位数字，1 开头
9

10
验证行为：
11
- 每个字段失焦时触发校验，不要边打字边校验
12
- 错误提示红色小字，显示在对应输入框正下方
13
- 密码强度用三段式进度条展示（弱/中/强）
14
- 确认密码字段只在密码字段有值后才启用
15

16
提交逻辑：
17
- 任一必填字段未通过校验时，提交按钮 disabled 且置灰
18
- 点击提交后按钮变成 loading 状态，显示"提交中..."
19
- 请求完成前禁止重复点击
20
- 成功后调用 onSuccess 回调并清空表单，失败后保留已填内容
21

22
代码要求：
23
- 用函数组件 + hooks，不用 class 组件
24
- 类型定义单独放一个 types.ts 文件
25
- 验证规则用 zod schema 定义，不要散落在组件里
26
- 错误信息统一放 constants.ts，支持国际化替换
27
- 样式用 Tailwind CSS，响应式适配移动端
28
- 关键逻辑加注释，特别是正则表达式要写清楚匹配什么
29

30
输出格式：
31
- RegisterForm.tsx（主组件）
32
- types.ts（类型定义）
33
- schema.ts（zod 验证规则）
34
- constants.ts（错误信息常量）
35
- 最后给一个使用示例

Show moreShow less

此 Prompt 的关键在于把每个细节写死，AI 没有发挥空间，输出质量稳定。

扩展知识#

1. 为什么用 React Hook Form 而不是受控组件？#

受控组件每个字段都要 useState，每次输入触发重渲染。5 个字段的表单打一个字渲染 5 遍。React Hook Form 使用非受控组件（ref），只在提交或校验时收集数据，性能差距可达 10 倍以上。

2. 验证库选型对比#

维度	zod	yup	joi
包体积	12KB	22KB	140KB
TypeScript 支持	原生完美	需额外配置	较弱
API 风格	链式调用	链式调用	配置对象
错误信息定制	简单直接	需额外配置	较麻烦
生态整合	React Hook Form 官方推荐	社区主流	Node 端

zod 与 TypeScript 配合最好，定义一个 schema 同时得到运行时校验和类型定义。

3. 写 Prompt 容易忽略的坑#

边界情况未提（如用户名前后空格不 trim） → AI 不会处理
联动关系不明确 → 需单独描述 if userType === 'company' then companyName.required = true
一次性生成复杂表单 → 建议分三轮：类型定义+验证 schema → 组件骨架 → 样式优化

面试官追问#

Q1：表单字段多了 Prompt 很长，怎么组织让 AI 不漏东西？#

A：用结构化格式（Markdown 表格或 YAML 缩进），每个字段单独一个 block。末尾加”请确认你理解了所有 N 个字段的要求后再生成代码”，让 AI 先复述需求。

Q2：验证逻辑复杂（字段联动），Prompt 怎么写？#

A：联动关系单独拎出来写，不要混在字段定义里。用伪代码或流程图表达，如 if userType === 'company' then companyName.required = true。越复杂的逻辑越要明确。

Q3：生成的代码有 bug，怎么通过改 Prompt 来修？#

A：把 bug 现象描述清楚喂回去，例如”确认密码字段校验有问题：密码清空后再填确认密码，校验不触发。请修复，确保密码字段变化时重新校验确认密码字段”。实质是将 debug 思路用自然语言表达。

Q4：React Hook Form 和 Formik 推荐哪个？#

A：新项目选 React Hook Form。性能：非受控组件重渲染少，快 2-3 倍；体积：8KB vs 12KB；API 更简洁。Formik 优势是社区资料多，但已非首选。

关键点#

设计包含上下文约束的 React 表单组件 Prompt#

要让大模型生成能直接使用的 React 表单组件，Prompt 必须覆盖四个维度：字段定义、验证规则、交互行为、代码规范。

以下是一个实战级 Prompt 模板：

1
用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
2
- 字段清单：
3
- 用户名：必填，2-10 个字符，只能包含字母数字下划线
4
- 邮箱：必填，标准邮箱格式
5
- 密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
6
- 确认密码：必填，必须和密码字段一致
7
- 手机号：选填，11 位数字，1 开头
8

9
验证行为：
10
- 每个字段失焦时触发校验，不要边打字边校验
11
- 错误提示红色小字，显示在对应输入框正下方
12
- 密码强度用三段式进度条展示（弱/中/强）
13
- 确认密码字段只在密码字段有值后才启用
14

15
提交逻辑：
16
- 任一必填字段未通过校验时，提交按钮 disabled 且置灰
17
- 点击提交后按钮变成 loading 状态，显示"提交中..."
18
- 请求完成前禁止重复点击
19
- 成功后调用 onSuccess 回调并清空表单，失败后保留已填内容
20

21
代码要求：
22
- 用函数组件 + hooks，不用 class 组件
23
- 类型定义单独放一个 types.ts 文件
24
- 验证规则用 zod schema 定义，不要散落在组件里
25
- 错误信息统一放 constants.ts，支持国际化替换
26
- 样式用 Tailwind CSS，响应式适配移动端
27
- 关键逻辑加注释，特别是正则表达式要写清楚匹配什么
28

29
输出格式：
30
- RegisterForm.tsx（主组件）
31
- types.ts（类型定义）
32
- schema.ts（zod 验证规则）
33
- constants.ts（错误信息常量）
34
- 最后给一个使用示例

Show moreShow less

此 Prompt 的关键在于把每个细节写死，AI 没有发挥空间，输出质量稳定。

受控组件每个字段都要 useState，每次输入触发重渲染。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

React_Form_Prompt_Design

要让大模型生成能直接使用的 React 表单组件，Prompt 必须覆盖四个维度：字段定义、验证规则、交互行为、代码规范。以下是一个实战级 Prompt 模板：

1
用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
2
- 字段清单：
3
- 用户名：必填，2-10 个字符，只能包含字母数字下划线
4
- 邮箱：必填，标准邮箱格式
5
- 密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
6
- 确认密码：必填，必须和密码字段一致
7
- 手机号：选填，11 位数字，1 开头
8

9
验证行为：
10
- 每个字段失焦时触发校验，不要边打字边校验
11
- 错误提示红色小字，显示在对应输入框正下方
12
- 密码强度用三段式进度条展示（弱/中/强）
13
- 确认密码字段只在密码字段有值后才启用
14

15
提交逻辑：
16
- 任一必填字段未通过校验时，提交按钮 disabled 且置灰
17
- 点击提交后按钮变成 loading 状态，显示"提交中..."
18
- 请求完成前禁止重复点击
19
- 成功后调用 onSuccess 回调并清空表单，失败后保留已填内容
20

21
代码要求：
22
- 用函数组件 + hooks，不用 class 组件
23
- 类型定义单独放一个 types.ts 文件
24
- 验证规则用 zod schema 定义，不要散落在组件里
25
- 错误信息统一放 constants.ts，支持国际化替换
26
- 样式用 Tailwind CSS，响应式适配移动端
27
- 关键逻辑加注释，特别是正则表达式要写清楚匹配什么
28

29
输出格式：
30
- RegisterForm.tsx（主组件）
31
- types.ts（类型定义）
32
- schema.ts（zod 验证规则）
33
- constants.ts（错误信息常量）
34
- 最后给一个使用示例

Show moreShow less

此 Prompt 的关键在于把每个细节写死，AI 没有发挥空间，输出质量稳定。

受控组件每个字段都要 useState，每次输入触发重渲染。5 个字段的表单打一个字渲染 5 遍。React Hook Form 使用非受控组件（ref），只在提交或校验时收集数据，性能差距可达 10 倍以上。
2. 验证库选型对比#

维度	zod	yup	joi
包体积	12KB	22KB	140KB
TypeScript 支持	原生完美	需额外配置	较弱
API 风格	链式调用	链式调用	配置对象
错误信息定制	简单直接	需额外配置	较麻烦
生态整合	React Hook Form 官方推荐	社区主流	Node 端

zod 与 TypeScript 配合最好，定义一个 schema 同时得到运行时校验和类型定义。

本文已做格式统一与噪声清理，保留原始语义。
、交互行为、代码规范**。以下是一个实战级 Prompt 模板：
用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
- 用户名：必填，2-10 个字符，只能包含字母数字下划线
- 邮箱：必填，标准邮箱格式
- 密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
本文已做格式统一与噪声清理，保留原始语义。

ReAct 模式构建自主规划智能体整理

Wed, 10 Jun 2026 00:00:00 GMT

ReAct_模式构建自主规划智能体#

问题#

ReAct_模式构建自主规划智能体

标准回答#

什么是 ReAct？#

如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？

ReAct（Reasoning + Acting） 是一种让大语言模型交替进行推理和行动的 Prompt 范式。模型在每一步先“思考”（Reasoning），然后“行动”（Acting），再根据观察结果（Observation）继续思考，形成闭环。这使得 AI 能主动调用工具、获取外部信息，并动态调整计划。

基于 ReAct 构建自主规划 Agent 的关键步骤： 定义工具集：提供模型可调用的外部函数（如搜索、计算器、API）。 设计 Prompt 格式：明确要求模型输出 Thought:（推理）、Action:（行动）、Observation:（观察）的结构。 解析与执行：应用层解析 Action: 字段，执行对应工具，将结果填入 Observation:。 循环迭代：重复上述过程，直到模型输出 Final Answer:。

示例 Prompt 结构：

1
你是一个能使用工具的智能体。你有以下工具：
2
- search(query): 搜索互联网
3
- calculate(expression): 计算数学表达式
4

5
请按以下格式回答：
6
Thought: 你的思考过程
7
Action: 工具名称(参数)
8
Observation: 工具返回结果
9
...（重复）
10
Final Answer: 最终答案

扩展知识#

1. ReAct 与 CoT 的区别#

CoT（Chain of Thought）：仅推理，不执行动作，适合数学逻辑题。
ReAct：推理 + 行动，通过外部反馈修正推理，适合需要实时信息或工具操作的任务。

2. 常见框架实现#

LangChain：AgentExecutor + ReActDocstoreAgent。
Spring AI：ChatClient + @Tool 注解 + Advisor 自定义输出解析。
AutoGen：多 Agent 协作中的 ReAct 模式。

3. 优化技巧#

限制最大循环次数：防止死循环。
错误恢复：当工具调用失败时，将错误信息作为 Observation 让模型自己修正。
思维链压缩：对历史 Thought 进行摘要，避免上下文超限。

面试官追问#

Q1：ReAct 模式会显著增加 token 消耗，如何优化？#

A：① 使用更精简的 Prompt 模板（如只要求输出 Action 和 Observation，隐藏 Thought）。② 对历史观察结果进行摘要。③ 设置最大循环次数，及时终止。

Q2：ReAct 与 Plan-and-Solve 模式有何不同？#

A：ReAct 是逐步决策，每次根据最新观察调整下一步；Plan-and-Solve 先生成完整计划再执行，灵活性较低，但 token 消耗更少。

Q3：如何防止模型在 ReAct 中编造不存在的工具？#

A：在 System Prompt 中明确列出可用工具，并强调“只能使用上述工具，不要编造”。应用层严格校验 Action 字段，只执行白名单内的工具。

总结#

ReAct 让 LLM 具备自主规划与工具使用能力，是构建智能 Agent 的核心模式之一。通过结构化的 Thought-Action-Observation 循环，模型能动态适应环境变化，解决复杂任务。实现时需注意工具集设计、循环控制与错误处理。

关键点#

什么是 ReAct？#
如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？
核心回答#

ReAct（Reasoning + Acting） 是一种让大语言模型交替进行推理和行动的 Prompt 范式。

模型在每一步先“思考”（Reasoning），然后“行动”（Acting），再根据观察结果（Observation）继续思考，形成闭环。
这使得 AI 能主动调用工具、获取外部信息，并动态调整计划。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

ReAct_模式构建自主规划智能体

什么是 ReAct？如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？#

核心回答#

基于 ReAct 构建自主规划 Agent 的关键步骤： 定义工具集：提供模型可调用的外部函数（如搜索、计算器、API）。
1. 设计 Prompt 格式：明确要求模型输出 Thought:（推理）、Action:（行动）、Observation:（观察）的结构。
1. 解析与执行：应用层解析 Action: 字段，执行对应工具，将结果填入 Observation:。
本文已做格式统一与噪声清理，保留原始语义。
如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？
ReAct（Reasoning + Acting） 是一种让大语言模型交替进行推理和行动的 Prompt 范式。模型在每一步先“思考”（Reasoning），然后“行动”（Acting），再根据观察结果（Observation）继续思考，形成闭环。这使得 AI 能主动调用工具、获取外部信息，并动态调整计划。
基于 ReAct 构建自主规划 Agent 的关键步骤：
1. 定义工具集：提供模型可调用的外部函数（如搜索、计算器、API）。
1. 设计 Prompt 格式：明确要求模型输出 Thought:（推理）、Action:（行动）、Observation:（观察）的结构。
本文已做格式统一与噪声清理，保留原始语义。

Spring AI Modular RAG Architecture 整理

Wed, 10 Jun 2026 00:00:00 GMT

Spring_AI_Modular_RAG_Architecture#

问题#

Spring_AI_Modular_RAG_Architecture

标准回答#

Spring AI 模块化 RAG 架构：预检索、检索、后检索三阶段#

Spring AI 提出的模块？ RAG 架构将检索增强生成过程分解为 预检索 (Pre-Retrieval)、检索 (Retrieval)、检索后 (Post-Retrieval) 三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。

阶段	职责	核心组件
预检索	接收原始查询，优化和转换，生成更适合检索的查询版本	QueryTransformer：`RewriteQueryTransformer`（改写）、`TranslationQueryTransformer`（翻译）、`CompressionQueryTransformer`（压缩历史）、`MultiQueryExpander`（扩展为多查询提高召回）
检索	使用优化后的查询，从知识库中搜索并召回最相关的文档片段	`DocumentRetriever`（如 `VectorStoreDocumentRetriever`），负责相似性搜索和元数据过滤；多源检索时使用 `DocumentJoiner` 合并结果
检索后	对检索到的文档集进一步处理和优化，筛选最适合作为上下文的文档	文档重排序、无关文档移除、文档内容压缩或摘要等。Spring AI 提供 `DocumentPostProcessor` API 支持自定义后处理（目前尚不成熟）

扩展知识#

1. 为什么需要模块化 RAG？#

灵活性：不同场景（如问答、摘要、代码生成）需要不同的检索策略
可维护性：各阶段独立演进，替换组件不影响整体流程
性能优化：可针对瓶颈阶段单独调优（如预检索阶段增加查询改写，提升召回率）

2. 各阶段的典型实现#

预检索：在多轮对话中，使用 CompressionQueryTransformer 将历史对话压缩与当前问题合并，避免上下文爆炸
检索：向量检索 + 关键词检索混合（Hybrid Search），提升召回和精度
检索后：使用 Cohere Rerank 或 Cross-Encoder 模型对召回文档重排序，将最相关的放在前面

3. 与传统 RAG 的区别#

传统 RAG 通常只包含“检索”和“生成”两步，查询优化和后处理硬编码或缺失。模块化 RAG 将每一步都暴露为可插拔组件，开发者可按需组合。

面试官追问#

Q1：预检索阶段的查询改写和扩展，会不会引入噪音？如何控制？#

A：可能。例如将单查询扩展为多个查询，可能召回不相关文档。控制方法：

限制扩展数量（如最多 3 个变体）
使用相似度阈值过滤低相关性结果
在检索后阶段用重排序模型降噪

Q2：检索阶段如果同时使用向量检索和关键词检索，结果如何合并？#

A：使用 DocumentJoiner，常见策略：

加权合并：向量和关键词得分加权平均
互惠排名融合：根据排名位置融合，避免分数尺度问题
分集合并：交替取出结果，保证多样性

Q3：检索后阶段的文档压缩/摘要，会不会丢失关键信息？#

A：会。但这是权衡 token 成本和信息完整性的必要手段。优化方法：

提取式摘要：保留原文中的关键句子，而非生成式摘要
分块压缩：对长文档按段落压缩，保留每段核心
重要性评分：只压缩低重要性片段

Q4：Spring AI 的模块化 RAG 与 LangChain 的 LCEL 有什么异同？#

A：

相同：都支持链式组合和组件化
不同：Spring AI 更强调阶段划分（预、检、后），并提供了官方 QueryTransformer 实现；LangChain 更灵活但需要开发者自行组装。Spring AI 与 Spring 生态集成更好（如结合 Spring Boot 配置）。

总结#

Spring AI 的模块化 RAG 架构通过将流程拆分为预检索、检索、后检索三个阶段，提供了高度的灵活性和可扩展性。开发者可根据业务需求替换或定制每个阶段的组件（如查询改写器、检索器、后处理器），实现更精准的检索增强生成。

关键点#

Spring AI 模块化 RAG 架构：预检索、检索、后检索三阶段#

Spring AI 提出的模块化 RAG 架构将检索增强生成过程分解为 预检索 (Pre-Retrieval)、检索 (Retrieval)、检索后 (Post-Retrieval) 三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。

| 阶段 | 职责 | 核心组件 | |------|------|----------| | 预检索 | 接收原始查询，优化和转换，生成更适合检索的查询版本 | QueryTransformer：RewriteQueryTransformer（改写）、TranslationQueryTransformer（翻译）、CompressionQueryTransformer（压缩历史）、MultiQueryExpander（扩展为多查询提高召回） | | 检索 | 使用优化后的查询，从知识库中搜索并召回最相关的文档片段 | DocumentRetriever（如 VectorStoreDocumentRetriever），负责相似性搜索和元数据过滤；多源检索时使用 DocumentJoiner 合并结果 | | 检索后 | 对检索到的文档集进一步处理和优化，筛选最适合作为上下文的文档 | 文档重排序、无关文档移除、文档内容压缩或摘要等。
Spring AI 提供 DocumentPostProcessor API 支持自定义后处理（目前尚不成熟） |

- 灵活性：不同场景（如问答、摘要、代码生成）需要不同的检索策略
可维护性：各阶段独立演进，替换组件不影响整体流程
性能优化：可针对瓶颈阶段单独调优（如预检索阶段增加查询改写，提升召回率）
预检索：在多轮对话中，使用 CompressionQueryTransformer 将历史对话压缩与当前问题合并，避免上下文爆炸
检索：向量检索 + 关键词检索混合（Hybrid Search），提升召回和精度
检索后：使用 Cohere Rerank 或 Cross-Encoder 模型对召回文档重排序，将最相关的放在前面

传统 RAG 通常只包含“检索”和“生成”两步，查询优化和后处理硬编码或缺失。

模块化 RAG 将每一步都暴露为可插拔组件，开发者可按需组合。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Spring_AI_Modular_RAG_Architecture

| 阶段 | 职责 | 核心组件 | |------|------|----------| | 预检索 | 接收原始查询，优化和转换，生成更适合检索的查询版本 | QueryTransformer：RewriteQueryTransformer（改写）、TranslationQueryTransformer（翻译）、CompressionQueryTransformer（压缩历史）、MultiQueryExpander（扩展为多查询提高召回） | | 检索 | 使用优化后的查询，从知识库中搜索并召回最相关的文档片段 | DocumentRetriever（如 VectorStoreDocumentRetriever），负责相似性搜索和元数据过滤；多源检索时使用 DocumentJoiner 合并结果 | | 检索后 | 对检索到的文档集进一步处理和优化，筛选最适合作为上下文的文档 | 文档重排序、无关文档移除、文档内容压缩或摘要等。Spring AI 提供 DocumentPostProcessor API 支持自定义后处理（目前尚不成熟） |

- 灵活性：不同场景（如问答、摘要、代码生成）需要不同的检索策略
可维护性：各阶段独立演进，替换组件不影响整体流程
性能优化：可针对瓶颈阶段单独调优（如预检索阶段增加查询改写，提升召回率）
预检索：在多轮对话中，使用 CompressionQueryTransformer 将历史对话压缩与当前问题合并，避免上下文爆炸
检索：向量检索 + 关键词检索混合（Hybrid Search），提升召回和精度
检索后：使用 Cohere Rerank 或 Cross-Encoder 模型对召回文档重排序，将最相关的放在前面

传统 RAG 通常只包含“检索”和“生成”两步，查询优化和后处理硬编码或缺失。模块化 RAG 将每一步都暴露为可插拔组件，开发者可按需组合。

A：可能。例如将单查询扩展为多个查询，可能召回不相关文档。控制方法：
限制扩展数量（如最多 3 个变体）
使用相似度阈值过滤低相关性结果
在检索后阶段用重排序模型降噪
本文已做格式统一与噪声清理，保留原始语义。
RAG 架构将检索增强生成过程分解为 预检索 (Pre-Retrieval)、检索 (Retrieval)、检索后 (Post-Retrieval) 三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。
| 阶段 | 职责 | 核心组件 |
|------|------|----------|
| 预检索 | 接收原始查询，优化和转换，生成更适合检索的查询版本 | QueryTransformer：RewriteQueryTransformer（改写）、TranslationQueryTransformer（翻译）、CompressionQueryTransformer（压缩历史）、MultiQueryExpander（扩展为多查询提高召回） |
| 检索 | 使用优化后的查询，从知识库中搜索并召回最相关的文档片段 | DocumentRetriever（如 VectorStoreDocumentRetriever），负责相似性搜索和元数据过滤；多源检索时使用 DocumentJoiner 合并结果 |
本文已做格式统一与噪声清理，保留原始语义。

SpringAI SuperAgent 应用与特性整理

Wed, 10 Jun 2026 00:00:00 GMT

SpringAI_SuperAgent_应用与特性#

问题#

SpringAI_SuperAgent_应用与特性

标准回答#

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？#

用到了哪些特性？

标准回答#

在 AI 超级智能体项目中，Spring AI 提供了构建模块化、可扩展 Agent 的核心能力，主要用到以下特性：

ChatClient 与工具调用：通过 @Tool 注解将业务能力（搜索、数据库查询等）暴露给 LLM，实现 ReAct 循环。
Advisor 链：在请求前后插入自定义逻辑，如日志、限流、记忆加载、内容安全过滤。
RAG 支持：利用 RetrievalAugmentationAdvisor 集成向量存储，实现知识库增强生成。
多模型抽象：统一接口支持 OpenAI、Ollama、Claude 等，便于切换或混合调用。
Function Calling 与 Stream：支持流式输出与并行工具调用，提升响应速度。

典型架构：

Controller：接收用户请求，调用 ChatClient。
Service + @Tool：封装内部 API 或第三方服务。
Memory Advisor：加载长期记忆并写回。
Observability：集成 Micrometer 追踪 Token 消耗与调用链。

扩展知识#

1. 高级特性使用场景#

多模态输入：通过 ChatClient 支持图片+文本混合 prompt。
结构化输出：利用 BeanOutputConverter 强制模型返回 JSON 对象。
动态工具选择：根据用户意图通过 PromptRequest 动态注册工具集。

2. 性能优化实践#

缓存：对常用 RAG 结果启用 Caffeine 本地缓存。
批处理：多个工具调用合并为一次 ChatClient 请求。
超时与重试：配置 RetryTemplate 应对模型 API 不稳定。

面试官追问#

Q1：如何保证 Super Agent 的长期记忆不膨胀？#

A：采用分层记忆：短期滑动窗口 + 长期向量检索。每晚让 Agent 自我总结，将重要事实写入长期库，丢弃临时细节。

Q2：如何处理工具调用中的依赖关系（如先搜索后计算）？#

A：在 Prompt 中明确任务步骤，或使用 SequentialToolExecutor 编排。Spring AI 本身不强制顺序，但可通过 Advice 实现自定义编排器。

Q3：Spring AI 与 LangChain 相比有何优劣？#

A：Spring AI 与 Spring Boot 生态无缝集成，适合 Java 技术栈企业；LangChain 生态更丰富，但 Python 依赖较重。

关键点#

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？#
用到了哪些特性？
核心回答#

在 AI 超级智能体项目中，Spring AI 提供了构建模块化、可扩展 Agent 的核心能力，主要用到以下特性：

ChatClient 与工具调用：通过 @Tool 注解将业务能力（搜索、数据库查询等）暴露给 LLM，实现 ReAct 循环。

1. Advisor 链：在请求前后插入自定义逻辑，如日志、限流、记忆加载、内容安全过滤。
1. RAG 支持：利用 RetrievalAugmentationAdvisor 集成向量存储，实现知识库增强生成。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

SpringAI_SuperAgent_应用与特性

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？用到了哪些特性？#

核心回答#

在 AI 超级智能体项目中，Spring AI 提供了构建模块化、可扩展 Agent 的核心能力，主要用到以下特性：

ChatClient 与工具调用：通过 @Tool 注解将业务能力（搜索、数据库查询等）暴露给 LLM，实现 ReAct 循环。

1. Advisor 链：在请求前后插入自定义逻辑，如日志、限流、记忆加载、内容安全过滤。
1. RAG 支持：利用 RetrievalAugmentationAdvisor 集成向量存储，实现知识库增强生成。
1. 多模型抽象：统一接口支持 OpenAI、Ollama、Claude 等，便于切换或混合调用。
本文已做格式统一与噪声清理，保留原始语义。
在 AI 超级智能体项目中，Spring AI 提供了构建模块化、可扩展 Agent 的核心能力，主要用到以下特性：
1. ChatClient 与工具调用：通过 @Tool 注解将业务能力（搜索、数据库查询等）暴露给 LLM，实现 ReAct 循环。
1. Advisor 链：在请求前后插入自定义逻辑，如日志、限流、记忆加载、内容安全过滤。
1. RAG 支持：利用 RetrievalAugmentationAdvisor 集成向量存储，实现知识库增强生成。
1. 多模型抽象：统一接口支持 OpenAI、Ollama、Claude 等，便于切换或混合调用。
本文已做格式统一与噪声清理，保留原始语义。

System Prompt Agent职责与长Prompt处理整理

Wed, 10 Jun 2026 00:00:00 GMT

System_Prompt_Agent职责与长Prompt处理#

问题#

System_Prompt_Agent职责与长Prompt处理

标准回答#

System Prompt 在 Agent 系统中的职责与长 Prompt 处理策略#

System Prompt 是？ Agent 的“操作系统”，承载了所有行为的底层规则。在 Agent 系统中，其职责可归为五类： 角色定义和行为准则：告诉模型“你是谁”（编程助手、客服等），并约束语气、风格和边界。 工具使用规范和约束：告知有哪些工具可用、如何调用、何时使用。 输出格式要求：规定回复格式（JSON、Markdown、消息标签等）。 安全与权限控制：设定禁止行为（危险命令、信息泄露等），划清红线。 上下文信息补充：提供当前运行环境（工作目录、时间、用户身份、技能清单等）。

当 System Prompt 越来越长时，处理策略为 “拆、选、扔”：

拆：按职责拆分为独立模块。
选：根据当前任务场景只注入相关模块。
扔：将稳定不变的知识移出 prompt，放入外部文件或知识库，按需读取。

扩展知识#

1. 模块化组装方案（以 OpenClaw 为例）#

OpenClaw 将 System Prompt 拆为三层：

基础层（每次必加）：身份声明、安全红线、工具列表及调用规范。
场景层（按需加载）：技能提示、记忆召回、消息路由、语音合成等。
动态层（每次生成）：当前时间、工作目录、用户白名单、沙箱信息等。

同时支持 分级加载：通过 promptMode 参数控制加载级别：

完整模式：主 Agent 使用。
精简模式：子 Agent 使用（仅核心模块）。
最小模式：仅身份声明。

2. 插件化扩展机制#

通过钩子（Hook）在 System Prompt 拼装前注入内容。插件有四种注入方式：

替换系统提示（覆盖全部）
头部追加（适合静态指令，可缓存）
尾部追加（同样可缓存）
对话层注入（动态上下文，每轮变化）

优先级机制（priority 数值）解决冲突：高优先级覆盖低优先级的 systemPrompt 字段；拼接型字段按优先级顺序拼接。

3. 长 System Prompt 的性能影响#

Token 消耗与延迟：Prompt 越长，每次请求成本越高。按需加载可显著降低子 Agent 的开销。
Prompt Cache：LLM 提供商（如 Anthropic、OpenAI）支持对不变部分缓存，第二次请求不重复计费。因此将稳定内容放在系统提示层（头部/尾部追加）有利于缓存命中。

4. 业界其他方案对比#

Cursor：全量加载极长 System Prompt，依赖模型长上下文能力，适合场景单一的应用。
Devin：将规则编码为代码逻辑，灵活性较低但减少 prompt 依赖。
LangChain：模板化组装，Callbacks 偏向观测，prompt 注入灵活度不如 OpenClaw 的四字段钩子。

面试官追问#

Q1：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？#

A：纯靠 System Prompt 不够。必须在代码层面做硬校验：路径白名单、危险命令拦截等。OpenClaw 采用分层防御：System Prompt 中的安全模块作为第一道防线，工具执行层的 before_tool_call 钩子和审批机制提供真正保障。

Q2：模块拼接顺序会影响模型行为吗？#

A：会。模型对开头和结尾关注度更高。OpenClaw 的固定顺序为：Identity → Tooling → Safety（最前面），Skills → Memory（中间），Runtime 信息（最后），符合“重要内容靠前”原则。

Q3：按需读取外部文件不也消耗 token 吗？如何判断何时放 prompt 里、何时放外部？#

A：判断标准：频率和体积。每次请求都需要的信息放 prompt 里，偶尔用到的放外部；体积小（<500 token）可直接放，体积大且使用频率低于 30% 时放外部更经济。OpenClaw 的 Skills 模块正是此思路：prompt 中只放技能目录，需要时再读取完整 SKILL.md。

Q4：多个插件通过钩子注入 System Prompt 时如何解决冲突？#

A：通过优先级机制。priority 数值越大越先执行。对于 systemPrompt 字段，后执行的覆盖先执行的（高优先级覆盖低优先级）；对于 prependContext、appendSystemContext 等拼接字段，按优先级顺序依次拼接，不覆盖。开发者如需覆盖核心 prompt，应设高优先级并使用 systemPrompt 字段；若仅追加内容，用拼接字段避免冲突。

关键点#

System Prompt 在 Agent 系统中的职责与长 Prompt 处理策略#

System Prompt 是 Agent 的“操作系统”，承载了所有行为的底层规则。

在 Agent 系统中，其职责可归为五类： 角色定义和行为准则：告诉模型“你是谁”（编程助手、客服等），并约束语气、风格和边界。
1. 工具使用规范和约束：告知有哪些工具可用、如何调用、何时使用。
1. 输出格式要求：规定回复格式（JSON、Markdown、消息标签等）。
1. 安全与权限控制：设定禁止行为（危险命令、信息泄露等），划清红线。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

System_Prompt_Agent职责与长Prompt处理

System Prompt 是 Agent 的“操作系统”，承载了所有行为的底层规则。在 Agent 系统中，其职责可归为五类： 角色定义和行为准则：告诉模型“你是谁”（编程助手、客服等），并约束语气、风格和边界。

2. 工具使用规范和约束：告知有哪些工具可用、如何调用、何时使用。
1. 输出格式要求：规定回复格式（JSON、Markdown、消息标签等）。
1. 安全与权限控制：设定禁止行为（危险命令、信息泄露等），划清红线。
1. 上下文信息补充：提供当前运行环境（工作目录、时间、用户身份、技能清单等）。
本文已做格式统一与噪声清理，保留原始语义。
Agent 的“操作系统”，承载了所有行为的底层规则。在 Agent 系统中，其职责可归为五类：
1. 角色定义和行为准则：告诉模型“你是谁”（编程助手、客服等），并约束语气、风格和边界。
1. 工具使用规范和约束：告知有哪些工具可用、如何调用、何时使用。
1. 输出格式要求：规定回复格式（JSON、Markdown、消息标签等）。
1. 安全与权限控制：设定禁止行为（危险命令、信息泄露等），划清红线。
本文已做格式统一与噪声清理，保留原始语义。

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？整理

Wed, 10 Jun 2026 00:00:00 GMT

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？#

问题#

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？

标准回答#

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2296面试问答System Prompt 就是 Agent 的”操作系统”，所有行为的底层规则都写在这里面。简单理解：每次你跟 ChatGPT、Cursor 这类 AI 工具对话时，你看到的只是 User Prompt（你的提问），但在你看不见的地方，开发者已经预先塞了一大段”隐藏指令”告诉模型该怎么表现，这段隐藏指令就是 System Prompt。Agent 系统比普通聊天复杂得多，所以它的 System Prompt 也更长、职责更重。它承载的职责可以归成五类：1）角色定义和行为准则：告诉模型”你是谁”，比如你是一个编程助手、客服机器人还是数据分析师，同时约束它的语气、风格和边界。

2）工具使用规范和约束：Agent 最核心的能力是”能调用工具”（读文件、跑命令、搜索网页等），System Prompt 要告诉模型有哪些工具可用、每个工具怎么调、什么场景该用哪个。

3）输出格式要求：规定模型以什么格式回复，比如 JSON、还是 markdown？消息标签怎么打、多通道消息怎么路由、静默回复用什么标记等。

4）安全与权限控制：设定模型不能做什么，比如不能执行危险命令、不能泄露内部配置、不能擅自做破坏性操作等。这相当于给 AI 划红线。

5）上下文信息补充：把当前运行环境的关键信息（工作目录、当前时间、用户身份、技能清单）告诉模型，让它的回答更贴合当前场景。至于 System Prompt 越来越长怎么办，核心策略就三个字：拆、选、扔。拆，是把 System Prompt 按职责拆成独立模块，每个模块管一件事。选，是根据当前任务场景只注入相关模块，不需要的不塞进去。扔，是把稳定不变的知识从 prompt 里移出去，放到外部文件或知识库里，让 Agent 需要的时候通过工具调用自己去读。

扩展知识#

模块化组装方案以 OpenClaw 为例，它的 System Prompt 不是一整坨字符串，而是拆成了十几个独立模块，每次请求时按需拼接。这些模块可以分成三层来理解：第一层：基础身份与安全（每次必加）身份声明：一句话告诉模型”你是谁”，这是整个 prompt 的锚点安全红线：写明不能自我复制、不能绕过安全机制、不能追求超出用户请求的目标工具列表：根据权限策略过滤后，列出当前可用的工具及调用规范工具调用风格：低风险操作不用解释直接调、敏感操作要先跟用户确认第二层：场景能力模块（按需加载）技能提示：告诉 Agent “你有哪些预装技能可以激活”，类似手机里的 App 列表记忆召回：指导模型在回答前先搜索历史记忆，避免”失忆”消息路由：跨通道（Signal、Telegram、Discord 等）发消息的规则语音合成：只有开启了 TTS 功能才注入第三层：动态运行时上下文（每次请求动态生成）当前时间、工作目录、操作系统、shell 类型等环境信息授权白名单用户列表沙箱信息（如果 Agent 跑在 Docker 里，要告诉它路径映射关系）项目配置文件的内容（行为规则、人格语气、用户偏好等）还有个关键设计：分级加载。OpenClaw 用一个加载级别参数控制注入哪些模块：完整模式：加载全部模块，主 Agent 用精简模式：只保留工具列表、工作目录、运行时信息等核心模块，子 Agent 用（子 Agent 不需要消息路由、心跳这些能力）最小模式：只返回一句身份声明这样同一套代码就能服务不同角色，子 Agent 不用背负主 Agent 那几千 token 的冗余指令。这种拆法的好处：每个模块独立维护、独立测试。加一个新功能不用在一个几千行的字符串里找位置插入，直接新增一个模块就行。插件化扩展机制除了内置模块，OpenClaw 还支持第三方插件向 System Prompt 注入内容。原理是在 System Prompt 即将拼装完成时，系统广播一个信号：“我要构建 prompt 了，谁想加点东西？” 注册了这个钩子（Hook）的插件就能在这时候把自己的内容塞进去。插件有四种注入方式：替换系统提示：直接覆盖整个 System Prompt（后注册的覆盖先注册的）系统提示头部追加：拼到 System Prompt 开头，适合静态指令，能被 LLM 的 prompt cache 缓存系统提示尾部追加：拼到 System Prompt 末尾，同样可缓存对话层注入：放到用户消息前面，适合每轮可能变化的动态上下文比如一个”代码规范检查”插件，可以通过钩子把当前项目的编码规范注入到 System Prompt 里，Agent 写代码时就会自动遵守这些规范。不需要改任何核心代码。长 System Prompt 的性能影响System Prompt 越长，每次请求消耗的 token 就越多，响应延迟也会上去。所以”按需加载”不只是架构上好看，在成本上也是刚需。一个代码审查任务根本不需要知道消息路由规范，一个简单问答也不需要加载完整的工具列表。模块化拼接 + 分级加载，能让子 Agent 的 prompt 比主 Agent 短得多，直接节省 token 开销。同时，prompt cache（提示缓存）也是降本的重要手段。很多 LLM 提供商（如 Anthropic、OpenAI）支持对 System Prompt 中不变的部分做缓存，第二次请求如果 prompt 前缀没变，就不重复计算 token 费用。所以插件注入方式才区分了”系统提示层”和”对话层”：把稳定内容放系统提示里吃缓存，动态内容走对话层每轮注入。业界其他方案的对比Cursor 的做法是把大量规则写进 System Prompt，然后靠模型的长上下文能力硬扛，简单粗暴但有效。它的 System Prompt 非常长（包含工具说明、代码引用格式、提交规范等等），但因为 Cursor 面向的场景相对单一（代码编辑），所以每次都全量加载也还能接受。Devin 走的是另一个极端，把很多行为规则编码成代码逻辑而不是自然语言 prompt，减少对 System Prompt 的依赖，但灵活性就差一些，改规则要改代码，不像改 prompt 那样随时能调。LangChain 的 Agent 框架用模板化的方式组装 prompt，跟 OpenClaw 思路类似，也有 Callbacks 系统可以在生命周期各节点插入逻辑，但它的 Callbacks 更偏”观测”（日志、追踪），在 prompt 注入这个环节的灵活度不如 OpenClaw 的四字段钩子精细。其实模块化组装 + 按需加载已经成了 Agent 系统处理 System Prompt 的主流方案，OpenClaw 在这个基础上加了分级加载（promptMode）和四字段插件钩子，算是做到了比较好的平衡。

面试官追问#

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？回答：纯靠 System Prompt 写安全规则肯定不够，模型层面的 prompt injection（用户故意构造输入来”欺骗”模型忽略之前的指令）防不胜防。所以关键操作必须在代码层面做硬校验，比如文件操作要做路径白名单检查，危险命令要在执行层面拦截，不能只靠 System Prompt 里写一句”禁止执行 rm -rf”就完事了。OpenClaw 的做法就是这样分层的：System Prompt 里有 Safety 模块写明安全红线（第一道防线，降低模型主动犯错的概率），但真正的保障在工具执行层。比如before_tool_call钩子可以在工具真正执行前拦截或修改参数，exec 工具有审批机制（用户要/approve才能执行敏感命令）。- 提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？
回答：会的，研究表明模型对 System Prompt 开头和结尾的内容关注度更高，中间部分容易被”稀释”（这跟人类阅读习惯类似）。所以最核心的身份定义和安全规则一般放在最前面，工具列表和格式要求放中间，动态上下文信息放后面。OpenClaw 的模块拼接顺序是固定写在buildAgentSystemPrompt函数里的：Identity → Tooling → Safety 在最前面，Skills → Memory 等能力模块在中间，Runtime 信息放最后。这个顺序符合”重要内容靠前”的通用原则。- 提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？
回答：判断标准就两条。第一看频率，每次请求都需要用到的信息放 prompt 里，偶尔才用到的放外部。第二看体积，几十个 token 的信息直接放 prompt 里没关系，但如果是几千 token 的编码规范文档，放外部按需读取更划算。读文件虽然也消耗 token，但它是”用到才花钱”，比每次请求都带上要省得多。一般来说，超过 500 token 且使用频率低于 30% 的信息，放外部就更经济。OpenClaw 的 Skills 模块就是这个思路：System Prompt 里只放一个技能目录（很短），模型判断需要某个技能时再通过 read 工具去读完整的 SKILL.md 文件。- 提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？
回答：完全可能冲突。比如两个插件一个要求”输出格式用 JSON”，另一个要求”输出格式用 Markdown”，模型就懵了。OpenClaw 的解决方案是优先级机制：每个钩子注册时可以指定priority数值，数值越大优先级越高，执行越靠前。对于systemPrompt字段，合并逻辑是”后执行的覆盖先执行的”（即低优先级插件的 systemPrompt 会被高优先级的覆盖）；对于prependContext、prependSystemContext、appendSystemContext这些拼接型字段，则是按优先级顺序依次拼接，不存在覆盖。所以插件开发者需要注意：如果你要覆盖核心 prompt，就设高优先级 + 用systemPrompt字段；如果只是追加上下文，用拼接型字段就不会跟别人冲突。作者：Yes面试鸭官方你是一个专业的数据分析助手，具有以下特征：
拥有 10 年数据科学经展开新页面打开2026-03-15 09:0300回复承担职责可归结五类：1 角色定义和行为准则 2.工具使用规范和约束 3.输出格式要求 4. 安全与权限控制 5.上下文信息补充

System prompt 越来越长：核心：拆、选、扔

拆，把System Prompt 按指责拆成独立模块，每个模块管一件事

选，根据当前任务场景只注入相关模块，不需要的展开新页面打开2026-03-14 11:4700回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

模块化组装方案插件化扩展机制长 System Prompt 的性能影响业界其他方案的对比

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

3）输出格式要求：规定模型以什么格式回复，比如 JSON、还是 markdown？消息标签怎么打、多通道消息怎么路由、静默回复用什么标记等。

4）安全与权限控制：设定模型不能做什么，比如不能执行危险命令、不能泄露内部配置、不能擅自做破坏性操作等。这相当于给 AI 划红线。

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？回答：纯靠 System Prompt 写安全规则肯定不够，模型层面的 prompt injection（用户故意构造输入来”欺骗”模型忽略之前的指令）防不胜防。所以关键操作必须在代码层面做硬校验，比如文件操作要做路径白名单检查，危险命令要在执行层面拦截，不能只靠 System Prompt 里写一句”禁止执行 rm -rf”就完事了。OpenClaw 的做法就是这样分层的：System Prompt 里有 Safety 模块写明安全红线（第一道防线，降低模型主动犯错的概率），但真正的保障在工具执行层。比如before_tool_call钩子可以在工具真正执行前拦截或修改参数，exec 工具有审批机制（用户要/approve才能执行敏感命令）。- 提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？
回答：会的，研究表明模型对 System Prompt 开头和结尾的内容关注度更高，中间部分容易被”稀释”（这跟人类阅读习惯类似）。所以最核心的身份定义和安全规则一般放在最前面，工具列表和格式要求放中间，动态上下文信息放后面。OpenClaw 的模块拼接顺序是固定写在buildAgentSystemPrompt函数里的：Identity → Tooling → Safety 在最前面，Skills → Memory 等能力模块在中间，Runtime 信息放最后。这个顺序符合”重要内容靠前”的通用原则。- 提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？
回答：判断标准就两条。第一看频率，每次请求都需要用到的信息放 prompt 里，偶尔才用到的放外部。第二看体积，几十个 token 的信息直接放 prompt 里没关系，但如果是几千 token 的编码规范文档，放外部按需读取更划算。读文件虽然也消耗 token，但它是”用到才花钱”，比每次请求都带上要省得多。一般来说，超过 500 token 且使用频率低于 30% 的信息，放外部就更经济。OpenClaw 的 Skills 模块就是这个思路：System Prompt 里只放一个技能目录（很短），模型判断需要某个技能时再通过 read 工具去读完整的 SKILL.md 文件。- 提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？
回答：完全可能冲突。比如两个插件一个要求”输出格式用 JSON”，另一个要求”输出格式用 Markdown”，模型就懵了。OpenClaw 的解决方案是优先级机制：每个钩子注册时可以指定priority数值，数值越大优先级越高，执行越靠前。对于systemPrompt字段，合并逻辑是”后执行的覆盖先执行的”（即低优先级插件的 systemPrompt 会被高优先级的覆盖）；对于prependContext、prependSystemContext、appendSystemContext这些拼接型字段，则是按优先级顺序依次拼接，不存在覆盖。所以插件开发者需要注意：如果你要覆盖核心 prompt，就设高优先级 + 用systemPrompt字段；如果只是追加上下文，用拼接型字段就不会跟别人冲突。作者：Yes面试鸭官方你是一个专业的数据分析助手，具有以下特征：
拥有 10 年数据科学经展开新页面打开2026-03-15 09:0300回复承担职责可归结五类：1 角色定义和行为准则 2.工具使用规范和约束 3.输出格式要求 4. 安全与权限控制 5.上下文信息补充

System prompt 越来越长：核心：拆、选、扔

拆，把System Prompt 按指责拆成独立模块，每个模块管一件事

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

模块化组装方案插件化扩展机制长 System Prompt 的性能影响业界其他方案的对比

来源: System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？.mhtml

关键点#

System Prompt 在 Agent 系统中承载了哪些职责？#
如果 System Prompt 越来越长，你会怎么处理？
问题#

System Prompt 在 Agent 系统中承载了哪些职责？

如果 System Prompt 越来越长，你会怎么处理？
NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2296面试问答System Prompt 就是 Agent 的”操作系统”，所有行为的底层规则都写在这里面。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？

标准回答#
问题#

3）输出格式要求：规定模型以什么格式回复，比如 JSON、还是 markdown？消息标签怎么打、多通道消息怎么路由、静默回复用什么标记等。

4）安全与权限控制：设定模型不能做什么，比如不能执行危险命令、不能泄露内部配置、不能擅自做破坏性操作等。这相当于给 AI 划红线。

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？回答：纯靠 System Prompt 写安全规则肯定不够，模型层面的 prompt injection（用户故意构造输入来”欺骗”模型忽略之前的指令）防不胜防。所以关键操作必须在代码层面做硬校验，比如文件操作要做路径白名单检查，危险命令要在执行层面拦截，不能只靠 System Prompt 里写一句”禁止执行 rm -rf”就完事了。OpenClaw 的做法就是这样分层的：System Prompt 里有 Safety 模块写明安全红线（第一道防线，降低模型主动犯错的概率），但真正的保障在工具执行层。比如before_tool_call钩子可以在工具真正执行前拦截或修改参数，exec 工具有审批机制（用户要/approve才能执行敏感命令）。- 提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？
回答：会的，研究表明模型对 System Prompt 开头和结尾的内容关注度更高，中间部分容易被”稀释”（这跟人类阅读习惯类似）。所以最核心的身份定义和安全规则一般放在最前面，工具列表和格式要求放中间，动态上下文信息放后面。OpenClaw 的模块拼接顺序是固定写在buildAgentSystemPrompt函数里的：Identity → Tooling → Safety 在最前面，Skills → Memory 等能力模块在中间，Runtime 信息放最后。这个顺序符合”重要内容靠前”的通用原则。- 提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？
回答：判断标准就两条。第一看频率，每次请求都需要用到的信息放 prompt 里，偶尔才用到的放外部。第二看体积，几十个 token 的信息直接放 prompt 里没关系，但如果是几千 token 的编码规范文档，放外部按需读取更划算。读文件虽然也消耗 token，但它是”用到才花钱”，比每次请求都带上要省得多。一般来说，超过 500 token 且使用频率低于 30% 的信息，放外部就更经济。OpenClaw 的 Skills 模块就是这个思路：System Prompt 里只放一个技能目录（很短），模型判断需要某个技能时再通过 read 工具去读完整的 SKILL.md 文件。- 提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？
回答：完全可能冲突。比如两个插件一个要求”输出格式用 JSON”，另一个要求”输出格式用 Markdown”，模型就懵了。OpenClaw 的解决方案是优先级机制：每个钩子注册时可以指定priority数值，数值越大优先级越高，执行越靠前。对于systemPrompt字段，合并逻辑是”后执行的覆盖先执行的”（即低优先级插件的 systemPrompt 会被高优先级的覆盖）；对于prependContext、prependSystemContext、appendSystemContext这些拼接型字段，则是按优先级顺序依次拼接，不存在覆盖。所以插件开发者需要注意：如果你要覆盖核心 prompt，就设高优先级 + 用systemPrompt字段；如果只是追加上下文，用拼接型字段就不会跟别人冲突。作者：Yes面试鸭官方你是一个专业的数据分析助手，具有以下特征：
拥有 10 年数据科学经展开新页面打开2026-03-15 09:0300回复承担职责可归结五类：1 角色定义和行为准则 2.工具使用规范和约束 3.输出格式要求 4. 安全与权限控制 5.上下文信息补充

System prompt 越来越长：核心：拆、选、扔

拆，把System Prompt 按指责拆成独立模块，每个模块管一件事

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

模块化组装方案插件化扩展机制长 System Prompt 的性能影响业界其他方案的对比

3）输出格式要求：规定模型以什么格式回复，比如 JSON、还是 markdown？消息标签怎么打、多通道消息怎么路由、静默回复用什么标记等。

4）安全与权限控制：设定模型不能做什么，比如不能执行危险命令、不能泄露内部配置、不能擅自做破坏性操作等。这相当于给 AI 划红线。

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？回答：纯靠 System Prompt 写安全规则肯定不够，模型层面的 prompt injection（用户故意构造输入来”欺骗”模型忽略之前的指令）防不胜防。所以关键操作必须在代码层面做硬校验，比如文件操作要做路径白名单检查，危险命令要在执行层面拦截，不能只靠 System Prompt 里写一句”禁止执行 rm -rf”就完事了。OpenClaw 的做法就是这样分层的：System Prompt 里有 Safety 模块写明安全红线（第一道防线，降低模型主动犯错的概率），但真正的保障在工具执行层。比如before_tool_call钩子可以在工具真正执行前拦截或修改参数，exec 工具有审批机制（用户要/approve才能执行敏感命令）。- 提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？
回答：会的，研究表明模型对 System Prompt 开头和结尾的内容关注度更高，中间部分容易被”稀释”（这跟人类阅读习惯类似）。所以最核心的身份定义和安全规则一般放在最前面，工具列表和格式要求放中间，动态上下文信息放后面。OpenClaw 的模块拼接顺序是固定写在buildAgentSystemPrompt函数里的：Identity → Tooling → Safety 在最前面，Skills → Memory 等能力模块在中间，Runtime 信息放最后。这个顺序符合”重要内容靠前”的通用原则。- 提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？
回答：判断标准就两条。第一看频率，每次请求都需要用到的信息放 prompt 里，偶尔才用到的放外部。第二看体积，几十个 token 的信息直接放 prompt 里没关系，但如果是几千 token 的编码规范文档，放外部按需读取更划算。读文件虽然也消耗 token，但它是”用到才花钱”，比每次请求都带上要省得多。一般来说，超过 500 token 且使用频率低于 30% 的信息，放外部就更经济。OpenClaw 的 Skills 模块就是这个思路：System Prompt 里只放一个技能目录（很短），模型判断需要某个技能时再通过 read 工具去读完整的 SKILL.md 文件。- 提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？
回答：完全可能冲突。比如两个插件一个要求”输出格式用 JSON”，另一个要求”输出格式用 Markdown”，模型就懵了。OpenClaw 的解决方案是优先级机制：每个钩子注册时可以指定priority数值，数值越大优先级越高，执行越靠前。对于systemPrompt字段，合并逻辑是”后执行的覆盖先执行的”（即低优先级插件的 systemPrompt 会被高优先级的覆盖）；对于prependContext、prependSystemContext、appendSystemContext这些拼接型字段，则是按优先级顺序依次拼接，不存在覆盖。所以插件开发者需要注意：如果你要覆盖核心 prompt，就设高优先级 + 用systemPrompt字段；如果只是追加上下文，用拼接型字段就不会跟别人冲突。作者：Yes面试鸭官方你是一个专业的数据分析助手，具有以下特征：
拥有 10 年数据科学经展开新页面打开2026-03-15 09:0300回复承担职责可归结五类：1 角色定义和行为准则 2.工具使用规范和约束 3.输出格式要求 4. 安全与权限控制 5.上下文信息补充

System prompt 越来越长：核心：拆、选、扔

拆，把System Prompt 按指责拆成独立模块，每个模块管一件事

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

模块化组装方案插件化扩展机制长 System Prompt 的性能影响业界其他方案的对比

来源: System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？.mhtml

System Prompt 在 Agent 系统中承载了哪些职责？#
- 如果 System Prompt 越来越长，你会怎么处理？
- 问题#

System Prompt 在 Agent 系统中承载了哪些职责？

本文已做格式统一与噪声清理，保留原始语义。
System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？#
System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？
System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？#
1. System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2296面试问答System Prompt 就是 Agent 的”操作系统”，所有行为的底层规则都写在这里面。简单理解：每次你跟 ChatGPT、Cursor 这类 AI 工具对话时，你看到的只是 User Prompt（你的提问），但在你看不见的地方，开发者已经预先塞了一大段”隐藏指令”告诉模型该怎么表现，这段隐藏指令就是 System Prompt。Agent 系统比普通聊天复杂得多，所以它的 System Prompt 也更长、职责更重。它承载的职责可以归成五类：1）角色定义和行为准则：告诉模型”你是谁”，比如你是一个编程助手、客服机器人还是数据分析师，同时约束它的语气、风格和边界。

3）输出格式要求：规定模型以什么格式回复，比如 JSON、还是 markdown？消息标签怎么打、多通道消息怎么路由、静默回复用什么标记等。

4）安全与权限控制：设定模型不能做什么，比如不能执行危险命令、不能泄露内部配置、不能擅自做破坏性操作等。这相当于给 AI 划红线。

提问：System Prompt 里的安全规则真的靠谱吗？用户通过 prompt injection 绕过去怎么办？回答：纯靠 System Prompt 写安全规则肯定不够，模型层面的 prompt injection（用户故意构造输入来”欺骗”模型忽略之前的指令）防不胜防。所以关键操作必须在代码层面做硬校验，比如文件操作要做路径白名单检查，危险命令要在执行层面拦截，不能只靠 System Prompt 里写一句”禁止执行 rm -rf”就完事了。OpenClaw 的做法就是这样分层的：System Prompt 里有 Safety 模块写明安全红线（第一道防线，降低模型主动犯错的概率），但真正的保障在工具执行层。比如before_tool_call钩子可以在工具真正执行前拦截或修改参数，exec 工具有审批机制（用户要/approve才能执行敏感命令）。- 提问：模块化拼接 System Prompt 的时候，模块之间的顺序会影响模型的行为吗？
回答：会的，研究表明模型对 System Prompt 开头和结尾的内容关注度更高，中间部分容易被”稀释”（这跟人类阅读习惯类似）。所以最核心的身份定义和安全规则一般放在最前面，工具列表和格式要求放中间，动态上下文信息放后面。OpenClaw 的模块拼接顺序是固定写在buildAgentSystemPrompt函数里的：Identity → Tooling → Safety 在最前面，Skills → Memory 等能力模块在中间，Runtime 信息放最后。这个顺序符合”重要内容靠前”的通用原则。- 提问：如果把知识移到外部文件让 Agent 按需读取，模型读文件这个动作本身不也消耗 token 吗？怎么判断什么时候该放 prompt 里，什么时候该放外部？
回答：判断标准就两条。第一看频率，每次请求都需要用到的信息放 prompt 里，偶尔才用到的放外部。第二看体积，几十个 token 的信息直接放 prompt 里没关系，但如果是几千 token 的编码规范文档，放外部按需读取更划算。读文件虽然也消耗 token，但它是”用到才花钱”，比每次请求都带上要省得多。一般来说，超过 500 token 且使用频率低于 30% 的信息，放外部就更经济。OpenClaw 的 Skills 模块就是这个思路：System Prompt 里只放一个技能目录（很短），模型判断需要某个技能时再通过 read 工具去读完整的 SKILL.md 文件。- 提问：多个插件同时通过钩子注入 System Prompt，有没有冲突的可能？怎么解决？
回答：完全可能冲突。比如两个插件一个要求”输出格式用 JSON”，另一个要求”输出格式用 Markdown”，模型就懵了。OpenClaw 的解决方案是优先级机制：每个钩子注册时可以指定priority数值，数值越大优先级越高，执行越靠前。对于systemPrompt字段，合并逻辑是”后执行的覆盖先执行的”（即低优先级插件的 systemPrompt 会被高优先级的覆盖）；对于prependContext、prependSystemContext、appendSystemContext这些拼接型字段，则是按优先级顺序依次拼接，不存在覆盖。所以插件开发者需要注意：如果你要覆盖核心 prompt，就设高优先级 + 用systemPrompt字段；如果只是追加上下文，用拼接型字段就不会跟别人冲突。作者：Yes面试鸭官方- 你是一个专业的数据分析助手，具有以下特征：
本文已做格式统一与噪声清理，保留原始语义。

Tool Calling Complete Link 整理

Wed, 10 Jun 2026 00:00:00 GMT

Tool_Calling_Complete_Link#

问题#

Tool_Calling_Complete_Link

标准回答#

Tool Calling（工具调用）完整链路：定义、调用与回传#

Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统？行 → 结果回传。

打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。

1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

工具的名字
一段自然语言描述
参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

2. LLM 决策调用#

LLM 收到用户消息和工具列表后，若判断需要调用工具，返回一个特殊的 tool_use 消息（OpenAI 用 tool_calls，Anthropic 用 tool_use），包含工具名和填好的参数 JSON。注意：LLM 只是”说”要调什么工具、传什么参数，它自己不会执行。

3. 系统执行#

系统侧拿到 tool_use 后，解析出工具名，找到本地注册的对应函数，传入参数执行。

4. 结果回传#

执行完拿到结果，包装成 tool_result 消息追加到对话历史，再发回给 LLM。LLM 看到后有两种选择：

信息够了 → 直接生成最终回答
需要更多信息 → 再发一个 tool_use，形成循环

完整链路：

1
用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

扩展知识#

1. 从 Function Calling 到 Tool Calling 的演进#

Function Calling（OpenAI 2023.06）：一次只能调一个函数
Tool Calling（2023.11）：支持 parallel tool calls，LLM 一次返回多个 tool_use，系统并行执行，一轮搞定多查询场景

不同厂商在 Schema 处理上有差异：Gemini 不支持 patternProperties，xAI 不支持 minLength/maxLength，OpenAI 要求参数顶层必须是 type: "object"。工程上需要一层 Schema 归一化来抹平差异。

2. 工具结果的上下文管理#

工具返回数据量可能很大（如代码搜索返回 50KB）。生产级系统一般做截断：

head+tail 保留：取开头和结尾各一部分，中间用省略标记替代
设置单条上限：如占上下文窗口 20%-30% 或字符数硬上限

3. 安全与权限控制#

工具调用是 Agent 系统中最容易出安全问题的环节。LLM 可能被 prompt injection 诱导调用不该调的工具（删除文件、发送邮件）。生产环境至少做三件事： 工具白名单：只暴露当前场景必需的工具 参数校验：服务端做 Schema 验证和业务规则校验 敏感操作加人工确认（如 LangChain 的 HumanApprovalCallbackHandler）

4. 错误处理和重试#

工具执行失败是常态（网络超时、API 限流、参数格式错误）。好的做法：

将错误信息包装成 tool_result 返回给 LLM，让它自己决定怎么处理
设置最大重试次数（一般 3-5 次），超时强制返回，避免死循环

面试官追问#

Q1：LLM 返回的工具参数格式不对（少必填字段或类型不匹配），怎么处理？#

A：两层防线。第一层：系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型会自己修正参数重新调用。第二层：设置重试上限（一般 3 次），避免来回纠错死循环。

Q2：parallel tool calls 并行执行多个工具时，其中一个失败怎么办？#

A：各工具的执行结果独立回传，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，类似 Promise.allSettled 的思路。

Q3：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？#

A：

RAG：提前检索、一次性注入，把相关文档片段塞进 prompt，适合知识查询类场景
Tool Calling：按需执行、多轮交互，LLM 动态决定要不要调、调哪个，适合需要实时数据或执行副作用的场景（查数据库、发请求、操作文件系统）

简单说：RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。

Q4：怎么让 LLM 更准确地选择正确的工具？#

A：

写好 description：写清楚工具干什么、什么场景该用、什么场景不该用；参数的 description 也要写明白（如”用户的唯一标识符，必须是数字格式”）
控制工具数量：超过 15-20 个时，LLM 选择准确率明显下降。解决方案：分场景加载不同工具集，或做一层路由先判断意图再加载对应工具

关键点#

Tool Calling（工具调用）完整链路：定义、调用与回传#

Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。

打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。
Tool Calling 就是这个”下命令再拿报告”的标准化流程。
1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

工具的名字
一段自然语言描述
参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。

示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

LLM 收到用户消息和工具列表后，若判断需要调用工具，返回一个特殊的 tool_use 消息（OpenAI 用 tool_calls，Anthropic 用 tool_use），包含工具名和填好的参数 JSON。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Tool_Calling_Complete_Link

Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。

打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。
1. 工具定义#

每个工具本质上是一段 JSON Schema，包含：

工具的名字
一段自然语言描述
参数的类型约束

LLM 不直接执行代码，只认这段 Schema 文本。示例：

1
{
2
"name": "get_weather",
3
"description": "查询指定城市的当前天气",
4
"parameters": {
5
"type": "object",
6
"properties": {
7
"city": { "type": "string", "description": "城市名称" }
8
},
9
"required": ["city"]
10
}
11
}

3. 系统执行#

系统侧拿到 tool_use 后，解析出工具名，找到本地注册的对应函数，传入参数执行。

4. 结果回传#

执行完拿到结果，包装成 tool_result 消息追加到对话历史，再发回给 LLM。LLM 看到后有两种选择：

信息够了 → 直接生成最终回答
需要更多信息 → 再发一个 tool_use，形成循环

完整链路：

1
用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

Function Calling（OpenAI 2023.06）：一次只能调一个函数
Tool Calling（2023.11）：支持 parallel tool calls，LLM 一次返回多个 tool_use，系统并行执行，一轮搞定多查询场景

本文已做格式统一与噪声清理，保留原始语义。
行 → 结果回传**。
打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。
1. 工具定义#
每个工具本质上是一段 JSON Schema，包含：
- 工具的名字
本文已做格式统一与噪声清理，保留原始语义。

Tool Calling SpringAI 整理

Wed, 10 Jun 2026 00:00:00 GMT

Tool_Calling_SpringAI#

问题#

Tool_Calling_SpringAI

标准回答#

什么是工具调用 Tool Calling？#

如何利用 Spring AI 实现工具调用？

Tool Calling（工具调用） 是一种让大语言模型能够请求调用外部函数或 API 的机制。模型不直接执行代码，而是输出结构化的调用请求（函数名和参数），由应用程序负责实际执行并将结果回传给模型。这使 LLM 能够获取实时信息、操作外部系统、执行计算等。

在 Spring AI 中实现工具调用： 定义工具（Function）：使用 @Tool 注解或实现 Function 接口。 注册工具：在 ChatClient 或 ChatModel 配置中注册工具 Bean。 发起请求：模型自动识别需要调用工具的场景，返回 ToolCall 对象。 执行与回传：应用执行工具后，将结果作为 ToolExecutionResult 消息追加到对话中，模型基于结果生成最终回答。

示例代码：

1
@Component
2
public class WeatherService {
3
@Tool(description = "查询指定城市的当前天气")
4
public String getWeather(String city) {
5
// 实现天气查询逻辑
6
return "晴天，25°C";
7
}
8
}
9

10
// 配置 ChatClient
11
@Bean
12
ChatClient chatClient(ChatModel chatModel, WeatherService weatherService) {
13
return ChatClient.builder(chatModel)
14
.defaultTools(weatherService)
15
.build();
16
}
17

18
// 使用
19
String response = chatClient.prompt()
20
.user("北京今天天气怎么样？")
21
.call()
22
.content();

Show moreShow less

Spring AI 自动处理工具调用的完整链路：模型返回 tool_calls → 框架执行对应方法 → 结果回填 → 模型生成最终回复。

扩展知识#

1. Tool Calling 的工作流程#

第一步：用户消息发送给 LLM，同时附上可用工具的定义（JSON Schema）。
第二步：LLM 判断是否需要调用工具。如果是，返回包含 tool_calls 字段的响应（工具名和参数）。
第三步：应用解析 tool_calls，执行对应函数，获得结果。
第四步：应用将结果作为 tool 角色的消息再次发送给 LLM。
第五步：LLM 基于工具结果生成最终回答，或继续请求调用其他工具。

2. Spring AI 的工具注册方式#

@Tool 注解：在任意 Spring Bean 的方法上使用，框架自动扫描并注册。
FunctionCallback 接口：手动实现 call 方法，通过 ChatClient.Builder.defaultFunctions() 注册。
动态工具：通过 Prompt 的 options 参数动态传入工具实例。

3. 处理并行工具调用#

Spring AI 支持模型一次返回多个 tool_calls，框架默认串行执行，也可以配置线程池并行执行。

4. 错误处理与重试#

工具执行抛异常时，Spring AI 会将异常信息作为 tool 消息返回给模型，让模型自行决定下一步（如修正参数重试或报告错误）。
可以配置 RetryTemplate 对工具调用进行重试。

面试官追问#

Q1：Tool Calling 和 Function Calling 是一回事吗？#

A：本质相同，但 OpenAI 在 2023 年 11 月将 functions 参数升级为 tools，支持并行调用和更丰富的工具类型（如代码解释器）。Spring AI 统一抽象为工具。

Q2：如何处理工具返回的数据过大导致上下文超限？#

A：Spring AI 不提供自动截断，但可以在工具方法内部对结果进行摘要、截断或只返回关键信息。也可以结合 Spring AI 的 Advice 对工具结果进行后处理。

Q3：如何让模型在特定条件下才调用工具？#

A：通过 @Tool 的 description 写清楚工具的适用场景，并利用 System Prompt 引导模型的行为。复杂场景可自定义 ToolCallingChatClient 进行前置判断。

总结#

Spring AI 简化了 Tool Calling 的集成，开发者只需定义带 @Tool 注解的方法，框架自动完成函数调用链路。这为构建具备行动能力的智能 Agent 提供了基础。

关键点#

什么是工具调用 Tool Calling？#
如何利用 Spring AI 实现工具调用？
核心回答#

Tool Calling（工具调用） 是一种让大语言模型能够请求调用外部函数或 API 的机制。

模型不直接执行代码，而是输出结构化的调用请求（函数名和参数），由应用程序负责实际执行并将结果回传给模型。
这使 LLM 能够获取实时信息、操作外部系统、执行计算等。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Tool_Calling_SpringAI

什么是工具调用 Tool Calling？如何利用 Spring AI 实现工具调用？#

核心回答#

在 Spring AI 中实现工具调用： 定义工具（Function）：使用 @Tool 注解或实现 Function 接口。
1. 注册工具：在 ChatClient 或 ChatModel 配置中注册工具 Bean。
1. 发起请求：模型自动识别需要调用工具的场景，返回 ToolCall 对象。
本文已做格式统一与噪声清理，保留原始语义。
如何利用 Spring AI 实现工具调用？
Tool Calling（工具调用） 是一种让大语言模型能够请求调用外部函数或 API 的机制。模型不直接执行代码，而是输出结构化的调用请求（函数名和参数），由应用程序负责实际执行并将结果回传给模型。这使 LLM 能够获取实时信息、操作外部系统、执行计算等。
在 Spring AI 中实现工具调用：
1. 定义工具（Function）：使用 @Tool 注解或实现 Function 接口。
1. 注册工具：在 ChatClient 或 ChatModel 配置中注册工具 Bean。
本文已做格式统一与噪声清理，保留原始语义。

Vector Search Metrics 整理

Wed, 10 Jun 2026 00:00:00 GMT

Vector_Search_Metrics#

问题#

Vector_Search_Metrics

标准回答#

向量搜索方法：余弦相似度、欧几里得距离、曼哈顿距离#

向量搜索的核心是衡量两个向量的相似程度，三种常见方法各有侧重：

| 方法 | 原理 | 取值范围 | 适用场景 | |---？ —|------|----------|----------| | 余弦相似度 | 计算两个向量的夹角，只看方向不看长度 | -1 到 1（1 表示完全同向） | 文本语义检索、推荐系统 | | 欧几里得距离 | 空间中两点之间的直线距离（勾股定理） | ≥ 0（越小越相似） | 图像检索、人脸识别 | | 曼哈顿距离 | 各维度差值绝对值之和（街区距离） | ≥ 0（越小越相似） | 网格坐标、稀疏高维数据 |

选型逻辑：

文本、推荐系统 → 余弦相似度
图像、视频检索 → 欧氏距离
网格坐标、稀疏高维数据 → 曼哈顿距离

扩展知识#

1. 数学公式与计算复杂度#

假设有两个 n 维向量 A 和 B：

余弦相似度：cos(θ) = (A·B) / (|A|×|B|)，需计算点积和模长。向量数据库（如 Faiss、Milvus）通常先对向量做 L2 归一化，归一化后余弦相似度等价于点积，可省去模长计算。
欧氏距离：√Σ(Ai - Bi)²，实际检索时常省略开根号，直接比较平方和以减少计算。
曼哈顿距离：Σ|Ai - Bi|，计算最简单，无乘法和开方，在高维稀疏场景效率最高。

2. 不同场景的选型考量#

文本语义检索：Embedding 模型输出的向量长度本身无业务含义（长文本 vs 短文本不影响语义），只关心方向，因此余弦相似度是默认选择。OpenAI 的 text-embedding-ada-002、BGE、M3E 等模型均建议使用余弦相似度。
图像检索：ResNet、CLIP 等视觉模型提取的特征向量，数值大小本身携带像素强度、纹理密度等信息。人脸识别领域（如 ArcFace、CosFace）虽名字带”Cos”，但推理时用欧氏距离效果更稳定。
推荐系统：用户点击、购买等行为天然是 0/1 稀疏向量，曼哈顿距离对个别维度的极端值不敏感，鲁棒性优于欧氏距离。

3. 向量数据库的索引加速#

暴力遍历 1 亿条向量不可行，需建索引：

IVF 系列：将向量空间切分成 1000-10000 个聚类中心，查询时只在最近的几个聚类中搜索。
HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确（Pinecone、Qdrant 默认使用）。
PQ 量化：将向量切分为子空间，每个子空间量化为码本，可压缩 32 倍，精度损失可控。

这些索引算法与距离度量正交，IVF 可搭配余弦、HNSW 可搭配欧氏，只需在建索引和查询时保持一致。

4. 实际踩坑经验#

向量未归一化就用余弦相似度：结果会很诡异。需先对向量做 L2 归一化再存入向量库。 欧氏距离对数值尺度敏感：若某几个维度的数值特别大，会主导距离。建议先做 z-score 标准化，让各维度方差一致。 维度灾难：当维度超过几百维，所有向量之间的距离趋于相等，区分度变差。此时降维或换用近似算法比纠结距离度量更重要。

面试官追问#

Q1：余弦相似度和欧氏距离在归一化向量上是等价的，为什么？#

A：归一化后所有向量模长为 1。欧氏距离平方 |A-B|² = |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者单调递减，排序结果完全一致。因此很多向量库内部会强制归一化，统一用点积计算，还能利用 SIMD 指令加速。

Q2：为什么曼哈顿距离对高维稀疏数据更友好？#

A：稀疏向量大部分维度为 0，有值的维度可能差异很大。欧氏距离会平方放大差异（差 10 → 贡献 100），少数极端维度主导距离；曼哈顿距离只是线性累加（差 10 → 贡献 10），对稀疏数据更稳定。

Q3：实际业务中如何选择距离度量？#

A：优先看 Embedding 模型的官方推荐（大多数文本模型建议余弦相似度）如果是自己训练的模型，看训练时 loss 函数用的什么度量，推理时保持一致拿不准时跑 A/B 测试，用业务指标决定，不要凭感觉猜测

关键点#

向量搜索方法：余弦相似度、欧几里得距离、曼哈顿距离#

向量搜索的核心是衡量两个向量的相似程度，三种常见方法各有侧重：

方法	原理	取值范围	适用场景
余弦相似度	计算两个向量的夹角，只看方向不看长度	-1 到 1（1 表示完全同向）	文本语义检索、推荐系统
欧几里得距离	空间中两点之间的直线距离（勾股定理）	≥ 0（越小越相似）	图像检索、人脸识别
曼哈顿距离	各维度差值绝对值之和（街区距离）	≥ 0（越小越相似）	网格坐标、稀疏高维数据

选型逻辑：

文本、推荐系统 → 余弦相似度
图像、视频检索 → 欧氏距离
网格坐标、稀疏高维数据 → 曼哈顿距离

假设有两个 n 维向量 A 和 B：

余弦相似度：cos(θ) = (A·B) / (|A|×|B|)，需计算点积和模长。
向量数据库（如 Faiss、Milvus）通常先对向量做 L2 归一化，归一化后余弦相似度等价于点积，可省去模长计算。
- 欧氏距离：√Σ(Ai - Bi)²，实际检索时常省略开根号，直接比较平方和以减少计算。
- 曼哈顿距离：Σ|Ai - Bi|，计算最简单，无乘法和开方，在高维稀疏场景效率最高。
2. 不同场景的选型考量#
文本语义检索：Embedding 模型输出的向量长度本身无业务含义（长文本 vs 短文本不影响语义），只关心方向，因此余弦相似度是默认选择。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

Vector_Search_Metrics

向量搜索的核心是衡量两个向量的相似程度，三种常见方法各有侧重：

方法	原理	取值范围	适用场景
余弦相似度	计算两个向量的夹角，只看方向不看长度	-1 到 1（1 表示完全同向）	文本语义检索、推荐系统
欧几里得距离	空间中两点之间的直线距离（勾股定理）	≥ 0（越小越相似）	图像检索、人脸识别
曼哈顿距离	各维度差值绝对值之和（街区距离）	≥ 0（越小越相似）	网格坐标、稀疏高维数据

选型逻辑：

文本、推荐系统 → 余弦相似度
图像、视频检索 → 欧氏距离
网格坐标、稀疏高维数据 → 曼哈顿距离

假设有两个 n 维向量 A 和 B：

余弦相似度：cos(θ) = (A·B) / (|A|×|B|)，需计算点积和模长。向量数据库（如 Faiss、Milvus）通常先对向量做 L2 归一化，归一化后余弦相似度等价于点积，可省去模长计算。
- 欧氏距离：√Σ(Ai - Bi)²，实际检索时常省略开根号，直接比较平方和以减少计算。
- 曼哈顿距离：Σ|Ai - Bi|，计算最简单，无乘法和开方，在高维稀疏场景效率最高。
2. 不同场景的选型考量#
文本语义检索：Embedding 模型输出的向量长度本身无业务含义（长文本 vs 短文本不影响语义），只关心方向，因此余弦相似度是默认选择。OpenAI 的 text-embedding-ada-002、BGE、M3E 等模型均建议使用余弦相似度。
- 图像检索：ResNet、CLIP 等视觉模型提取的特征向量，数值大小本身携带像素强度、纹理密度等信息。人脸识别领域（如 ArcFace、CosFace）虽名字带”Cos”，但推理时用欧氏距离效果更稳定。
本文已做格式统一与噪声清理，保留原始语义。
—|------|----------|----------|
| 余弦相似度 | 计算两个向量的夹角，只看方向不看长度 | -1 到 1（1 表示完全同向） | 文本语义检索、推荐系统 |
| 欧几里得距离 | 空间中两点之间的直线距离（勾股定理） | ≥ 0（越小越相似） | 图像检索、人脸识别 |
| 曼哈顿距离 | 各维度差值绝对值之和（街区距离） | ≥ 0（越小越相似） | 网格坐标、稀疏高维数据 |
- 文本、推荐系统 → 余弦相似度
本文已做格式统一与噪声清理，保留原始语义。

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？整理

Wed, 10 Jun 2026 00:00:00 GMT

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？#

问题#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？

标准回答#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

扩展知识#

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

面试官追问#

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

来源: 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？.mhtml

关键点#

什么是 Agent 的 Context Window？#
为什么它是 Agent 工程中最核心的约束之一？
问题#

什么是 Agent 的 Context Window？

为什么它是 Agent 工程中最核心的约束之一？
NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？

标准回答#
问题#

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

来源: 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？.mhtml

什么是 Agent 的 Context Window？#
- 为什么它是 Agent 工程中最核心的约束之一？
- 问题#

什么是 Agent 的 Context Window？

本文已做格式统一与噪声清理，保留原始语义。
什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？
什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？#
1. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方- Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:2813223. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方
本文已做格式统一与噪声清理，保留原始语义。

什么是 Re Reading？如何基于 Spring AI 实现 Re Reading Advisor？整理

Wed, 10 Jun 2026 00:00:00 GMT

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？#

问题#

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？

标准回答#

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？VIP中等后端编程导航标记分享131891Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。核心思想是，对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答，有文献研究证明这是有一定效果的。不过，这种方法会因为重复处理输入导致成本加倍，所以在面向 C 端开放的应用中需要谨慎使用。在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：1）创建自定义 Advisor 类：该类需要同时实现CallAroundAdvisor（用于同步请求）和StreamAroundAdvisor（用于流式请求）接口，让该类更通用

(在 Spring AI 1.0 版本中，上述两个接口需要更改为CallAdvisor和StreamAdvisor)2）修改用户提示词：在 Advisor 的前置处理逻辑中（例如aroundCall或aroundStream方法调用之前），对用户的原始输入文本进行改写。改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读，通过看源码能够看到提示词：▼markdown复制代码{Input_Query}

Read the question again: {Input_Query}其中，{Input_Query}是用户原始的提问内容。

3）传递给模型：将改写后的提示词传递给大语言模型进行处理。对复杂问题，重复阅读，让模型能够更好理解，从而生成更加准确的答案

Spring AI实现

1.可以通过自定义Advisor类进行实现

2.在拦截之后进行修改提示词

改写格式一般是将原始输入重新重复一遍（让模型再次读取一遍）

3.展开新页面打开2026-03-18 16:5200回复迷途者之博士退学中特训营重读是一种让LLM重新阅读问题，从而提高LLM推理能力的技术，核心思想就是，对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答，有文献研究证明这是有一定效果的，不过这种方法会因为重复处理请求导致api成本加倍，所以面对C端应用时需要谨慎使用。然后，我在项展开新页面打开2025-12-22 20:2600回复我一定要找到工作Re-Reading(重读)，核心思想是，对于复杂问题，让ai重复阅读一次问题，有助于模型更好地理解我们的问题，从而生成更准确的答案。缺点是：重复处理输入导致成本加倍，所以在面向 C端开放的应用中需要谨慎使用。在SpringAI中，可以通过自展开新页面打开2025-11-29 16:2600回复yyc什么是 Re-Reading?如何基于 Spring Al 实现 Re-Reading Advisor?Re-Reading（Re2）是通过让大语言模型重读问题提升推理能力的技术。核心思想是重复阅读帮助模型更好理解题意约束，生成更准确深入的回答。使用注意：文献证明有效，但因重复处理输展开新页面打开2025-11-13 17:2800回复XiCallAroundAdvidor以及StreamAroundAdvisor接口：展开新页面打开2025-09-23 12:5000回复面试鸭5102特训营Re-Reading也叫Read2，是指在AI遇到复杂问题的情况下，通过让AI重复阅读一次用户的提示词从而提高AI回复的准确度。

Read2的实现通过自定义一个advisor类，该advidor类实现CallAroundAdvidor以及StreamAroundAdvisor接口以及实现里面的方法，展开新页面打开2025-09-04 16:4000回复超大桶可乐特训营Re-Reading 是指在提示词中，显示的指示LLM重新阅读一遍用户的输入，这样可以让LLM的输出更准确。有文献研究表明这是一种有效的手段。具体实现时，通过定义一个ReReadingAdvisor，继承 BaseAdvisor 类，重写 before() 方法，将用户的提示修改为如下格展开新页面打开2025-08-26 15:0100回复拒绝内耗特训营ReReading简称Re2，实际上是一种提示词工程，它将用户的提示词重复了一遍，起到了一个强调的作用。我们可以利用 Advisor 接口，来实现一个Re-Reading Advisor，关键在于对用户的提示词进行修改。2025-08-04 18:0800回复云墨总结：Spring AI 的Re-reading（重读）Re-reading（重读）是 Spring AI 中用于对大模型返回的结果进行再次处理或解析的一种机制。核心作用：对 AI 模型生成的内容进行结构化提取或**格式转展开新页面打开2025-07-17 09:2600回复一口南瓜饼Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术

在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：

）创建自定义 Advisor 类：该类需要同时实现 CallAroundAdvisor（用于同步展开新页面打开2025-07-12 15:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？用到了哪些特性？上次浏览：2026-03-16 15:12:36你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？如何实现程序和 AI 大模型的集成？有哪些方式？Agent 死循环问题有遇到过吗？如何解决？如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？11764. 什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？VIP中等后端编程导航标记分享131891Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。核心思想是，对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答，有文献研究证明这是有一定效果的。不过，这种方法会因为重复处理输入导致成本加倍，所以在面向 C 端开放的应用中需要谨慎使用。在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：1）创建自定义 Advisor 类：该类需要同时实现CallAroundAdvisor（用于同步请求）和StreamAroundAdvisor（用于流式请求）接口，让该类更通用

Read the question again: {Input_Query}其中，{Input_Query}是用户原始的提问内容。

3）传递给模型：将改写后的提示词传递给大语言模型进行处理。对复杂问题，重复阅读，让模型能够更好理解，从而生成更加准确的答案

Spring AI实现

1.可以通过自定义Advisor类进行实现

2.在拦截之后进行修改提示词

改写格式一般是将原始输入重新重复一遍（让模型再次读取一遍）

在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

来源: 什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？.mhtml

关键点#

什么是 Re-Reading？#
如何基于 Spring AI 实现 Re-Reading Advisor？
问题#

什么是 Re-Reading？

如何基于 Spring AI 实现 Re-Reading Advisor？
VIP中等后端编程导航标记分享131891Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？

标准回答#
问题#

(在 Spring AI 1.0 版本中，上述两个接口需要更改为CallAdvisor和StreamAdvisor)2）修改用户提示词：在 Advisor 的前置处理逻辑中（例如aroundCall或aroundStream方法调用之前），对用户的原始输入文本进行改写。

改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读，通过看源码能够看到提示词：▼markdown复制代码{Input_Query}

Read the question again: {Input_Query}其中，{Input_Query}是用户原始的提问内容。

3）传递给模型：将改写后的提示词传递给大语言模型进行处理。对复杂问题，重复阅读，让模型能够更好理解，从而生成更加准确的答案

Spring AI实现

1.可以通过自定义Advisor类进行实现

2.在拦截之后进行修改提示词

改写格式一般是将原始输入重新重复一遍（让模型再次读取一遍）

Read2的实现通过自定义一个advisor类，该advidor类实现CallAroundAdvidor以及StreamAroundAdvisor接口以及实现里面的方法，展开新页面打开2025-09-04 16:4000回复超大桶可乐特训营Re-Reading 是指在提示词中，显示的指示LLM重新阅读一遍用户的输入，这样可以让LLM的输出更准确。有文献研究表明这是一种有效的手段。具体实现时，通过定义一个ReReadingAdvisor，继承 BaseAdvisor 类，重写 before() 方法，将用户的提示修改为如下格展开新页面打开2025-08-26 15:0100回复拒绝内耗特训营ReReading简称Re2，实际上是一种提示词工程，它将用户的提示词重复了一遍，起到了一个强调的作用。我们可以利用 Advisor 接口，来实现一个Re-Reading Advisor，关键在于对用户的提示词进行修改。2025-08-04 18:0800回复云墨总结：Spring AI 的Re-reading（重读）Re-reading（重读）是 Spring AI 中用于对大模型返回的结果进行再次处理或解析的一种机制。核心作用：对 AI 模型生成的内容进行结构化提取或**格式转展开新页面打开2025-07-17 09:2600回复一口南瓜饼Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术

在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

本文已做格式统一与噪声清理，保留原始语义。
什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？
什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？#
1. 什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？VIP中等后端编程导航标记分享131891Re-Reading (重读)，也称为 Re2，是一种通过让大语言模型重新阅读问题来提高其推理能力的技术。核心思想是，对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答，有文献研究证明这是有一定效果的。不过，这种方法会因为重复处理输入导致成本加倍，所以在面向 C 端开放的应用中需要谨慎使用。在 Spring AI 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：1）创建自定义 Advisor 类：该类需要同时实现CallAroundAdvisor（用于同步请求）和StreamAroundAdvisor（用于流式请求）接口，让该类更通用
(在 Spring AI 1.0 版本中，上述两个接口需要更改为CallAdvisor和StreamAdvisor)2）修改用户提示词：在 Advisor 的前置处理逻辑中（例如aroundCall或aroundStream方法调用之前），对用户的原始输入文本进行改写。改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读，通过看源码能够看到提示词：▼markdown复制代码{Input_Query}
Read the question again: {Input_Query}其中，{Input_Query}是用户原始的提问内容。

3）传递给模型：将改写后的提示词传递给大语言模型进行处理。

本文已做格式统一与噪声清理，保留原始语义。

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？整理

Wed, 10 Jun 2026 00:00:00 GMT

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？#

问题#

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？

标准回答#

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？VIP中等后端编程导航标记分享151441Spring AI 提出的模块化 RAG 架构是将整个检索增强生成过程分解为预检索、检索、检索后三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。

1）预检索阶段 (Pre-Retrieval)：职责：接收用户的原始查询，并对其进行优化和转换，生成更适合后续检索的查询版本。组件：包括各种QueryTransformer，如RewriteQueryTransformer（改写查询使其更清晰）、TranslationQueryTransformer（翻译查询）、CompressionQueryTransformer（在多轮对话中压缩历史和当前问题）、以及MultiQueryExpander（将单查询扩展为多查询，提高召回）。

2）检索阶段 (Retrieval)：职责：使用预检索阶段优化后的查询，从知识库中搜索并召回最相关的文档片段。组件：核心是DocumentRetriever（如VectorStoreDocumentRetriever），它负责执行相似性搜索并根据元数据过滤结果。如果涉及多源检索，还可能用到DocumentJoiner来合并结果。

3）检索后阶段 (Post-Retrieval)：职责：对检索到的文档集进行进一步处理和优化，筛选出最适合提供给大模型的上下文，可以解决上下文丢失问题、上下文长度限制，并减少冗余内容。组件：可能包括文档重排序、无关文档移除、文档内容压缩或摘要等。Spring AI 提供了DocumentPostProcessorAPI 来支持自定义的后处理逻辑，但目前并不成熟。预检索就是在用户输入提示词的时候。对用户的提示词进行查询重写，多查询扩展，查询压缩等操作，最终输出增强的用户查询

检索中就是将用户的增强查询从知识库中的文档进行搜索，最终输出相关文档的过程，展开新页面打开2026-02-26 16:5400回复我一定要找到工作Sprin⁠g AI 官方声称‌提供了一个 “模块化” 的 RAG ‎架构，用于优化大模‌型回复的准确性。

简单来说，⁠就是把整个文档过滤‌检索阶段拆分为：检索前、检索时、检索‎后，分别针对每个阶‌段提供了可自定义的组件。

• 1在预检索阶段，系统接收用户的原始查询，可以通过查询重写、多查询扩展展开新页面打开2025-12-04 23:2000回复yyc什么是 Spring Al 提出的模块化 RAG 架构?预检索、检索和后检索阶段各自负责什么?Spring AI 模块化 RAG 架构将检索增强生成过程分解为三个核心阶段，每个阶段包含可配置组件以提升大模型响应准确性和灵活性：1. 预检索阶段 (Pre-Retrieval)展开新页面打开2025-11-13 17:2200回复云墨Spring AI 模块化 RAG 三阶段总结模块化 RAG 定义Spring AI 的模块化 RAG（检索增强生成）是一种将 RAG 流程拆分为独立、可插拔组件的技术架构。它通过灵活组合不同模块（如检索、查询改写、生成等），实现高度定制化的知识增强生成流程。三阶段演进展开新页面打开2025-07-04 22:5500回复晚夜微雨问海棠特训营Spring AI 提出的模块化 RAG 架构解析Spring AI 提出的模块化 RAG (Retrieval-Augmented Generation) 架构是一种将检索增强生成过程分解为三个明确阶段的框架，以提高系统的灵活性、可维护性和性能。模块化 RAG 的三个阶段展开新页面打开2025-06-07 20:4200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

答案#

简单来说，⁠就是把整个文档过滤‌检索阶段拆分为：检索前、检索时、检索‎后，分别针对每个阶‌段提供了可自定义的组件。

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

来源: 什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？.mhtml

关键点#

什么是 Spring AI 提出的模块化 RAG 架构？#
预检索、检索和后检索阶段各自负责什么？
问题#

什么是 Spring AI 提出的模块化 RAG 架构？

预检索、检索和后检索阶段各自负责什么？
VIP中等后端编程导航标记分享151441Spring AI 提出的模块化 RAG 架构是将整个检索增强生成过程分解为预检索、检索、检索后三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？

标准回答#
问题#

3）检索后阶段 (Post-Retrieval)：职责：对检索到的文档集进行进一步处理和优化，筛选出最适合提供给大模型的上下文，可以解决上下文丢失问题、上下文长度限制，并减少冗余内容。组件：可能包括文档重排序、无关文档移除、文档内容压缩或摘要等。Spring AI 提供了DocumentPostProcessorAPI 来支持自定义的后处理逻辑，但目前并不成熟。- 预检索就是在用户输入提示词的时候。对用户的提示词进行查询重写，多查询扩展，查询压缩等操作，最终输出增强的用户查询

简单来说，⁠就是把整个文档过滤‌检索阶段拆分为：检索前、检索时、检索‎后，分别针对每个阶‌段提供了可自定义的组件。
本文已做格式统一与噪声清理，保留原始语义。
什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？
什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？#
1. 什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？VIP中等后端编程导航标记分享151441Spring AI 提出的模块化 RAG 架构是将整个检索增强生成过程分解为预检索、检索、检索后三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确性和灵活性。

3）检索后阶段 (Post-Retrieval)：职责：对检索到的文档集进行进一步处理和优化，筛选出最适合提供给大模型的上下文，可以解决上下文丢失问题、上下文长度限制，并减少冗余内容。组件：可能包括文档重排序、无关文档移除、文档内容压缩或摘要等。Spring AI 提供了DocumentPostProcessorAPI 来支持自定义的后处理逻辑，但目前并不成熟。- 预检索就是在用户输入提示词的时候。对用户的提示词进行查询重写，多查询扩展，查询压缩等操作，最终输出增强的用户查询

检索中就是将用户的增强查询从知识库中的文档进行搜索，最终输出相关文档的过程，展开新页面打开2026-02-26 16:5400回复我一定要找到工作Sprin⁠g AI 官方声称‌提供了一个 “模块化” 的 RAG ‎架构，用于优化大模‌型回复的准确性。
本文已做格式统一与噪声清理，保留原始语义。

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？整理

Wed, 10 Jun 2026 00:00:00 GMT

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？#

问题#

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？

标准回答#

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？VIP中等后端编程导航标记分享121354上下文查询增强是 RAG 流程中的一个核心环节，指的是把用户的原始查询与从知识库中检索到的相关文档进行结合，形成一个信息更丰富的增强提示，然后将这个增强提示提供给 AI，让模型能基于这些特定知识生成回答。主要作用是为大模型提供必要的、实时的外部知识，这样 AI 的回答就不仅仅依赖于其预训练的通用知识，提高答案的准确性、相关性和时效性。Spring AI 的RetrievalAugmentationAdvisor内部使用ContextualQueryAugmenter来实现上下文查询增强。当处理用户提出的无关问题时，ContextualQueryAugmenter提供了空上下文处理机制。我们可以配置ContextualQueryAugmenter的allowEmptyContext(false)，并提供一个自定义的emptyContextPromptTemplate。检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。默认情况下，RetrievalAugmentationAdvisor检索增强顾问内部就使用了上下文查询增强，当它没有找到相关文档时，它会指示模型不要回答用户查询。这是一种保守的策略，可以防止模型在没有足够信息的情况下生成不准确的展开新页面打开2025-12-04 23:1400回复axing特训营什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？上下文查询增强是 RAG 的核心步骤，它把用户的原始查询和检索到的相关文档结合，生成一个增强Prompt提供给大模型，让模型基于外部知识生成更准确、更相关的回答。这样可以让 AI 回答展开新页面打开2025-11-04 18:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

答案#

市面上有哪些主流的 LLM Agent 框架？各自的特点是什么？AutoGPT 如何实现自主决策？什么是 A2A 协议，它的核心架构及主要组件有哪些？什么是查询重写？它有什么作用？如何基于 Spring AI 实现查询重写？什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？上次浏览：2026-03-16 15:11:49什么是工具调用 Tool Calling？如何利用 Spring AI 实现工具调用？上次浏览：2026-03-16 15:11:24什么是 ReAct？如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？上次浏览：2026-03-16 15:12:08什么是 OpenManus？它的实现原理是什么？什么是 CoT 思维链？如何实现 CoT 思维链？如何保证 AI 应用的性能和稳定性？11775. 什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？VIP中等后端编程导航标记分享121354上下文查询增强是 RAG 流程中的一个核心环节，指的是把用户的原始查询与从知识库中检索到的相关文档进行结合，形成一个信息更丰富的增强提示，然后将这个增强提示提供给 AI，让模型能基于这些特定知识生成回答。主要作用是为大模型提供必要的、实时的外部知识，这样 AI 的回答就不仅仅依赖于其预训练的通用知识，提高答案的准确性、相关性和时效性。Spring AI 的RetrievalAugmentationAdvisor内部使用ContextualQueryAugmenter来实现上下文查询增强。当处理用户提出的无关问题时，ContextualQueryAugmenter提供了空上下文处理机制。我们可以配置ContextualQueryAugmenter的allowEmptyContext(false)，并提供一个自定义的emptyContextPromptTemplate。检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。默认情况下，RetrievalAugmentationAdvisor检索增强顾问内部就使用了上下文查询增强，当它没有找到相关文档时，它会指示模型不要回答用户查询。这是一种保守的策略，可以防止模型在没有足够信息的情况下生成不准确的展开新页面打开2025-12-04 23:1400回复axing特训营什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？上下文查询增强是 RAG 的核心步骤，它把用户的原始查询和检索到的相关文档结合，生成一个增强Prompt提供给大模型，让模型基于外部知识生成更准确、更相关的回答。这样可以让 AI 回答展开新页面打开2025-11-04 18:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

来源: 什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？.mhtml

关键点#

什么是上下文查询增强？#
它有什么作用？
如何基于 Spring AI 实现上下文查询增强来处理无关问题？
问题#

什么是上下文查询增强？

它有什么作用？

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？

标准回答#
问题#

检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。默认情况下，RetrievalAugmentationAdvisor检索增强顾问内部就使用了上下文查询增强，当它没有找到相关文档时，它会指示模型不要回答用户查询。这是一种保守的策略，可以防止模型在没有足够信息的情况下生成不准确的展开新页面打开2025-12-04 23:1400回复axing特训营什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？上下文查询增强是 RAG 的核心步骤，它把用户的原始查询和检索到的相关文档结合，生成一个增强Prompt提供给大模型，让模型基于外部知识生成更准确、更相关的回答。这样可以让 AI 回答展开新页面打开2025-11-04 18:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。默认情况下，RetrievalAugmentationAdvisor检索增强顾问内部就使用了上下文查询增强，当它没有找到相关文档时，它会指示模型不要回答用户查询。这是一种保守的策略，可以防止模型在没有足够信息的情况下生成不准确的展开新页面打开2025-12-04 23:1400回复axing特训营什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？上下文查询增强是 RAG 的核心步骤，它把用户的原始查询和检索到的相关文档结合，生成一个增强Prompt提供给大模型，让模型基于外部知识生成更准确、更相关的回答。这样可以让 AI 回答展开新页面打开2025-11-04 18:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

来源: 什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？.mhtml

什么是上下文查询增强？#
本文已做格式统一与噪声清理，保留原始语义。
什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？
什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？#
1. 什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？VIP中等后端编程导航标记分享121354上下文查询增强是 RAG 流程中的一个核心环节，指的是把用户的原始查询与从知识库中检索到的相关文档进行结合，形成一个信息更丰富的增强提示，然后将这个增强提示提供给 AI，让模型能基于这些特定知识生成回答。主要作用是为大模型提供必要的、实时的外部知识，这样 AI 的回答就不仅仅依赖于其预训练的通用知识，提高答案的准确性、相关性和时效性。Spring AI 的RetrievalAugmentationAdvisor内部使用ContextualQueryAugmenter来实现上下文查询增强。当处理用户提出的无关问题时，ContextualQueryAugmenter提供了空上下文处理机制。我们可以配置ContextualQueryAugmenter的allowEmptyContext(false)，并提供一个自定义的emptyContextPromptTemplate。检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。- 默认情况下，RetrievalAugmentationAdvisor检索增强顾问内部就使用了上下文查询增强，当它没有找到相关文档时，它会指示模型不要回答用户查询。这是一种保守的策略，可以防止模型在没有足够信息的情况下生成不准确的展开新页面打开2025-12-04 23:1400回复axing特训营什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？上下文查询增强是 RAG 的核心步骤，它把用户的原始查询和检索到的相关文档结合，生成一个增强Prompt提供给大模型，让模型基于外部知识生成更准确、更相关的回答。这样可以让 AI 回答展开新页面打开2025-11-04 18:5900回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  alt
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号
市面上有哪些主流的 LLM Agent 框架？各自的特点是什么？AutoGPT 如何实现自主决策？什么是 A2A 协议，它的核心架构及主要组件有哪些？什么是查询重写？它有什么作用？如何基于 Spring AI 实现查询重写？什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？上次浏览：2026-03-16 15:11:49什么是工具调用 Tool Calling？如何利用 Spring AI 实现工具调用？上次浏览：2026-03-16 15:11:24什么是 ReAct？如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？上次浏览：2026-03-16 15:12:08什么是 OpenManus？它的实现原理是什么？什么是 CoT 思维链？如何实现 CoT 思维链？如何保证 AI 应用的性能和稳定性？11775. 什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？VIP中等后端编程导航标记分享121354上下文查询增强是 RAG 流程中的一个核心环节，指的是把用户的原始查询与从知识库中检索到的相关文档进行结合，形成一个信息更丰富的增强提示，然后将这个增强提示提供给 AI，让模型能基于这些特定知识生成回答。主要作用是为大模型提供必要的、实时的外部知识，这样 AI 的回答就不仅仅依赖于其预训练的通用知识，提高答案的准确性、相关性和时效性。Spring AI 的RetrievalAugmentationAdvisor内部使用ContextualQueryAugmenter来实现上下文查询增强。当处理用户提出的无关问题时，ContextualQueryAugmenter提供了空上下文处理机制。我们可以配置ContextualQueryAugmenter的allowEmptyContext(false)，并提供一个自定义的emptyContextPromptTemplate。检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。在我们的项目中，这个自定义模板会引导 AI 礼貌地告知用户 “它只能回答恋爱相关的问题”，并给出联系客服的方式，优雅地处理了超出知识库范围的提问。
本文已做格式统一与噪声清理，保留原始语义。

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）整理

Wed, 10 Jun 2026 00:00:00 GMT

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）#

问题#

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提？等要求）

标准回答#

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）VIP中等大模型标记分享31022面试问答让大模型生成一个能直接用的 React 表单组件，Prompt 得把上下文约束写死，不然 AI 就会按自己的理解乱发挥。一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。

字段清单：

用户名：必填，2-10 个字符，只能包含字母数字下划线
邮箱：必填，标准邮箱格式
密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
确认密码：必填，必须和密码字段一致
手机号：选填，11 位数字，1 开头

验证行为：

每个字段失焦时触发校验，不要边打字边校验
错误提示红色小字，显示在对应输入框正下方
密码强度用三段式进度条展示（弱/中/强）
确认密码字段只在密码字段有值后才启用

提交逻辑：

任一必填字段未通过校验时，提交按钮 disabled 且置灰
点击提交后按钮变成 loading 状态，显示”提交中…”
请求完成前禁止重复点击
成功后调用 onSuccess 回调并清空表单，失败后保留已填内容

代码要求：

用函数组件 + hooks，不用 class 组件
类型定义单独放一个 types.ts 文件
验证规则用 zod schema 定义，不要散落在组件里
错误信息统一放 constants.ts，支持国际化替换
样式用 Tailwind CSS，响应式适配移动端
关键逻辑加注释，特别是正则表达式要写清楚匹配什么

输出格式：

RegisterForm.tsx（主组件）
types.ts（类型定义）
schema.ts（zod 验证规则）
constants.ts（错误信息常量）
最后给一个使用示例这个 Prompt 的关键在于把每个细节都定死了，AI 照着抄就行，没有发挥空间就不会出幺蛾子。

扩展知识#

为什么用 React Hook Form 而不是受控组件传统的受控组件写法，每个字段都要 useState，每次输入都触发 setState，组件就会重新渲染。5 个字段的表单，用户打一个字就要渲染 5 遍，字段多了性能很难看。React Hook Form 用的是非受控组件，通过 ref 直接读取 DOM 的值，只在提交或校验时才收集数据。同样 5 个字段，用户打字时组件压根不重渲染，性能差距能到 10 倍以上。而且受控组件写起来很啰嗦，每个字段都要写 value、onChange、错误状态，代码量轻松翻倍。React Hook Form 用 register 一行搞定，代码干净很多。验证库选型对比维度zodyupjoi包体积12KB22KB140KBTypeScript 支持原生，类型推导完美需要额外配置类型支持较弱API 风格链式调用，更现代链式调用配置对象式错误信息定制简单直接需要额外配置比较麻烦生态整合React Hook Form 官方推荐社区主流主要用在 Node 端运行时校验支持支持支持现在新项目基本都用 zod，跟 TypeScript 配合是最好的，定义一个 schema 就能同时得到运行时校验和类型定义，不用写两遍。写 Prompt 容易忽略的坑很多人写 Prompt 只关注主流程，边界情况完全不提。AI 默认是不会处理这些的，你不说它就不做。比如用户名前后带空格，不 trim 的话会存进数据库，后面登录的时候就对不上了。这种细节要在 Prompt 里明确写出来。分步生成 vs 一次性生成复杂表单不建议一个 Prompt 全搞定。更好的做法是分三轮：1）第一轮让 AI 生成类型定义和验证 schema，确认字段和规则没问题

2）第二轮基于第一轮的输出，生成组件骨架和基础交互

3）第三轮加上样式和性能优化每一轮都能检查，出问题好定位。一口气全塞进去，AI 经常顾此失彼，验证规则对了但交互逻辑不对，或者交互对了但样式乱七八糟。相关资源：React Hook Form 官方文档:https://react-hook-form.com/Tailwind CSS 官方文档:https://tailwindcss.com/Zod 类型验证库:https://github.com/colinhacks/zod

面试官追问#

提问：表单字段多了以后 Prompt 会很长，怎么组织才能让 AI 不漏东西？回答：用结构化格式来组织，比如 Markdown 表格或者 YAML 风格的缩进。每个字段单独一个 block，里面包含名称、类型、必填性、校验规则、错误提示。AI 对结构化数据的理解能力比纯文本强很多，漏东西的概率会低不少。另外可以在末尾加一句”请确认你理解了所有 N 个字段的要求后再生成代码”，让 AI 先复述一遍需求。- 提问：如果验证逻辑很复杂，比如字段之间有联动关系，Prompt 该怎么写？
回答：联动关系要单独拎出来写清楚，不要混在字段定义里。比如”当用户类型选择企业时，公司名称和营业执照号变成必填”，这种就单独一段描述。还可以用伪代码或者流程图来表达，比如”if userType === ‘company’ then companyName.required = true”。越复杂的逻辑越要写得明确，别指望 AI 能猜出你的意图。- 提问：生成的代码跑起来有 bug，怎么通过改 Prompt 来修而不是自己手动改？
回答：把 bug 现象描述清楚喂回去。比如”你生成的代码在确认密码字段校验时有问题，当密码字段清空后再填确认密码，校验不会触发。请修复这个问题，确保密码字段变化时会重新校验确认密码字段”。本质上就是把你 debug 的思路用自然语言写出来。如果 bug 很隐蔽，可以把出问题的代码段贴回去，让 AI 重点看那一块。- 提问：React Hook Form 和 Formik 你更推荐哪个？为什么？
回答：现在新项目肯定选 React Hook Form。性能上，React Hook Form 是非受控组件，重渲染次数少很多，官方 benchmark 显示能快 2-3 倍。体积上，React Hook Form 压缩后 8KB，Formik 要 12KB。API 上，React Hook Form 的 register 比 Formik 的 Field 组件更简洁。唯一 Formik 还有点优势的是社区资料多一些，毕竟出来得早，但 React Hook Form 现在文档也很完善了，上手不难。

为什么用 React Hook Form 而不是受控组件验证库选型对比写 Prompt 容易忽略的坑分步生成 vs 一次性生成

提问：表单字段多了以后 Prompt 会很长，怎么组织才能让 AI 不漏东西？提问：如果验证逻辑很复杂，比如字段之间有联动关系，Prompt 该怎么写？提问：生成的代码跑起来有 bug，怎么通过改 Prompt 来修而不是自己手动改？提问：React Hook Form 和 Formik 你更推荐哪个？为什么？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

解释LangChain框架中的Chain和Agent概念，并举例说明各自的应用场景上次浏览：2026-03-16 15:02:59什么是大模型的”涌现能力”？列举三种典型表现并解释其可能成因要让AI生成一个带表单验证的Vue3组件，请写出包含以下要素的Prompt上次浏览：2026-03-16 15:06:23假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）上次浏览：2026-03-16 15:07:05请描述使用LangChain构建一个文档问答系统的关键技术组件及实现步骤上次浏览：2026-03-16 15:07:08假设要开发一个智能工单分类系统，请拆解AI可参与的环节并说明技术选型思路当需要处理超长大模型上下文窗口限制时，有哪些可行的工程解决方案？请举例说明假设在电商系统中，哪些功能适合直接使用大模型完成，哪些需要结合工程化手段？上次浏览：2026-03-16 15:07:38假设请你设计一个医疗问诊系统，如何平衡AI幻觉带来的风险与效率提升？需要哪些技术手段？设计智能客服系统时，如何通过知识库构建解决长尾问题？请描述具体实现步骤11341. 假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）VIP中等大模型标记分享31022面试问答让大模型生成一个能直接用的 React 表单组件，Prompt 得把上下文约束写死，不然 AI 就会按自己的理解乱发挥。一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。

字段清单：

用户名：必填，2-10 个字符，只能包含字母数字下划线
邮箱：必填，标准邮箱格式
密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
确认密码：必填，必须和密码字段一致
手机号：选填，11 位数字，1 开头

验证行为：

每个字段失焦时触发校验，不要边打字边校验
错误提示红色小字，显示在对应输入框正下方
密码强度用三段式进度条展示（弱/中/强）
确认密码字段只在密码字段有值后才启用

提交逻辑：

任一必填字段未通过校验时，提交按钮 disabled 且置灰
点击提交后按钮变成 loading 状态，显示”提交中…”
请求完成前禁止重复点击
成功后调用 onSuccess 回调并清空表单，失败后保留已填内容

代码要求：

用函数组件 + hooks，不用 class 组件
类型定义单独放一个 types.ts 文件
验证规则用 zod schema 定义，不要散落在组件里
错误信息统一放 constants.ts，支持国际化替换
样式用 Tailwind CSS，响应式适配移动端
关键逻辑加注释，特别是正则表达式要写清楚匹配什么

输出格式：

RegisterForm.tsx（主组件）
types.ts（类型定义）
schema.ts（zod 验证规则）
constants.ts（错误信息常量）
最后给一个使用示例这个 Prompt 的关键在于把每个细节都定死了，AI 照着抄就行，没有发挥空间就不会出幺蛾子。

2）第二轮基于第一轮的输出，生成组件骨架和基础交互

提问：表单字段多了以后 Prompt 会很长，怎么组织才能让 AI 不漏东西？回答：用结构化格式来组织，比如 Markdown 表格或者 YAML 风格的缩进。每个字段单独一个 block，里面包含名称、类型、必填性、校验规则、错误提示。AI 对结构化数据的理解能力比纯文本强很多，漏东西的概率会低不少。另外可以在末尾加一句”请确认你理解了所有 N 个字段的要求后再生成代码”，让 AI 先复述一遍需求。- 提问：如果验证逻辑很复杂，比如字段之间有联动关系，Prompt 该怎么写？
回答：联动关系要单独拎出来写清楚，不要混在字段定义里。比如”当用户类型选择企业时，公司名称和营业执照号变成必填”，这种就单独一段描述。还可以用伪代码或者流程图来表达，比如”if userType === ‘company’ then companyName.required = true”。越复杂的逻辑越要写得明确，别指望 AI 能猜出你的意图。- 提问：生成的代码跑起来有 bug，怎么通过改 Prompt 来修而不是自己手动改？
回答：把 bug 现象描述清楚喂回去。比如”你生成的代码在确认密码字段校验时有问题，当密码字段清空后再填确认密码，校验不会触发。请修复这个问题，确保密码字段变化时会重新校验确认密码字段”。本质上就是把你 debug 的思路用自然语言写出来。如果 bug 很隐蔽，可以把出问题的代码段贴回去，让 AI 重点看那一块。- 提问：React Hook Form 和 Formik 你更推荐哪个？为什么？
回答：现在新项目肯定选 React Hook Form。性能上，React Hook Form 是非受控组件，重渲染次数少很多，官方 benchmark 显示能快 2-3 倍。体积上，React Hook Form 压缩后 8KB，Formik 要 12KB。API 上，React Hook Form 的 register 比 Formik 的 Field 组件更简洁。唯一 Formik 还有点优势的是社区资料多一些，毕竟出来得早，但 React Hook Form 现在文档也很完善了，上手不难。

为什么用 React Hook Form 而不是受控组件验证库选型对比写 Prompt 容易忽略的坑分步生成 vs 一次性生成

来源: 假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）.mhtml

关键点#

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）#

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）VIP中等大模型标记分享31022面试问答让大模型生成一个能直接用的 React 表单组件，Prompt 得把上下文约束写死，不然 AI 就会按自己的理解乱发挥。

一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。
直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
字段清单：
用户名：必填，2-10 个字符，只能包含字母数字下划线
邮箱：必填，标准邮箱格式
密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
确认密码：必填，必须和密码字段一致
手机号：选填，11 位数字，1 开头

验证行为：

每个字段失焦时触发校验，不要边打字边校验
错误提示红色小字，显示在对应输入框正下方
密码强度用三段式进度条展示（弱/中/强）
确认密码字段只在密码字段有值后才启用

提交逻辑：

任一必填字段未通过校验时，提交按钮 disabled 且置灰
点击提交后按钮变成 loading 状态，显示”提交中…”
请求完成前禁止重复点击
成功后调用 onSuccess 回调并清空表单，失败后保留已填内容

代码要求：

用函数组件 + hooks，不用 class 组件
类型定义单独放一个 types.ts 文件
验证规则用 zod schema 定义，不要散落在组件里
错误信息统一放 constants.ts，支持国际化替换
样式用 Tailwind CSS，响应式适配移动端
关键逻辑加注释，特别是正则表达式要写清楚匹配什么

输出格式：

RegisterForm.tsx（主组件）
types.ts（类型定义）
schema.ts（zod 验证规则）
constants.ts（错误信息常量）
最后给一个使用示例这个 Prompt 的关键在于把每个细节都定死了，AI 照着抄就行，没有发挥空间就不会出幺蛾子。

为什么用 React Hook Form 而不是受控组件传统的受控组件写法，每个字段都要 useState，每次输入都触发 setState，组件就会重新渲染。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）VIP中等大模型标记分享31022面试问答让大模型生成一个能直接用的 React 表单组件，Prompt 得把上下文约束写死，不然 AI 就会按自己的理解乱发挥。一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。

字段清单：
用户名：必填，2-10 个字符，只能包含字母数字下划线
邮箱：必填，标准邮箱格式
密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
确认密码：必填，必须和密码字段一致
手机号：选填，11 位数字，1 开头

验证行为：

每个字段失焦时触发校验，不要边打字边校验
错误提示红色小字，显示在对应输入框正下方
密码强度用三段式进度条展示（弱/中/强）
确认密码字段只在密码字段有值后才启用

提交逻辑：

任一必填字段未通过校验时，提交按钮 disabled 且置灰
点击提交后按钮变成 loading 状态，显示”提交中…”
请求完成前禁止重复点击
成功后调用 onSuccess 回调并清空表单，失败后保留已填内容

代码要求：

用函数组件 + hooks，不用 class 组件
类型定义单独放一个 types.ts 文件
验证规则用 zod schema 定义，不要散落在组件里
错误信息统一放 constants.ts，支持国际化替换
样式用 Tailwind CSS，响应式适配移动端
关键逻辑加注释，特别是正则表达式要写清楚匹配什么

输出格式：

RegisterForm.tsx（主组件）
types.ts（类型定义）
schema.ts（zod 验证规则）
constants.ts（错误信息常量）
最后给一个使用示例这个 Prompt 的关键在于把每个细节都定死了，AI 照着抄就行，没有发挥空间就不会出幺蛾子。

2）第二轮基于第一轮的输出，生成组件骨架和基础交互

提问：表单字段多了以后 Prompt 会很长，怎么组织才能让 AI 不漏东西？回答：用结构化格式来组织，比如 Markdown 表格或者 YAML 风格的缩进。每个字段单独一个 block，里面包含名称、类型、必填性、校验规则、错误提示。AI 对结构化数据的理解能力比纯文本强很多，漏东西的概率会低不少。另外可以在末尾加一句”请确认你理解了所有 N 个字段的要求后再生成代码”，让 AI 先复述一遍需求。- 提问：如果验证逻辑很复杂，比如字段之间有联动关系，Prompt 该怎么写？
回答：联动关系要单独拎出来写清楚，不要混在字段定义里。比如”当用户类型选择企业时，公司名称和营业执照号变成必填”，这种就单独一段描述。还可以用伪代码或者流程图来表达，比如”if userType === ‘company’ then companyName.required = true”。越复杂的逻辑越要写得明确，别指望 AI 能猜出你的意图。- 提问：生成的代码跑起来有 bug，怎么通过改 Prompt 来修而不是自己手动改？
回答：把 bug 现象描述清楚喂回去。比如”你生成的代码在确认密码字段校验时有问题，当密码字段清空后再填确认密码，校验不会触发。请修复这个问题，确保密码字段变化时会重新校验确认密码字段”。本质上就是把你 debug 的思路用自然语言写出来。如果 bug 很隐蔽，可以把出问题的代码段贴回去，让 AI 重点看那一块。- 提问：React Hook Form 和 Formik 你更推荐哪个？为什么？
回答：现在新项目肯定选 React Hook Form。性能上，React Hook Form 是非受控组件，重渲染次数少很多，官方 benchmark 显示能快 2-3 倍。体积上，React Hook Form 压缩后 8KB，Formik 要 12KB。API 上，React Hook Form 的 register 比 Formik 的 Field 组件更简洁。唯一 Formik 还有点优势的是社区资料多一些，毕竟出来得早，但 React Hook Form 现在文档也很完善了，上手不难。

为什么用 React Hook Form 而不是受控组件验证库选型对比写 Prompt 容易忽略的坑分步生成 vs 一次性生成

字段清单：
用户名：必填，2-10 个字符，只能包含字母数字下划线
邮箱：必填，标准邮箱格式
密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
确认密码：必填，必须和密码字段一致
手机号：选填，11 位数字，1 开头

验证行为：

每个字段失焦时触发校验，不要边打字边校验
错误提示红色小字，显示在对应输入框正下方
密码强度用三段式进度条展示（弱/中/强）
确认密码字段只在密码字段有值后才启用

提交逻辑：

任一必填字段未通过校验时，提交按钮 disabled 且置灰
点击提交后按钮变成 loading 状态，显示”提交中…”
请求完成前禁止重复点击
成功后调用 onSuccess 回调并清空表单，失败后保留已填内容

代码要求：

用函数组件 + hooks，不用 class 组件
类型定义单独放一个 types.ts 文件
验证规则用 zod schema 定义，不要散落在组件里
错误信息统一放 constants.ts，支持国际化替换
样式用 Tailwind CSS，响应式适配移动端
关键逻辑加注释，特别是正则表达式要写清楚匹配什么

输出格式：

RegisterForm.tsx（主组件）
types.ts（类型定义）
schema.ts（zod 验证规则）
constants.ts（错误信息常量）
最后给一个使用示例这个 Prompt 的关键在于把每个细节都定死了，AI 照着抄就行，没有发挥空间就不会出幺蛾子。

2）第二轮基于第一轮的输出，生成组件骨架和基础交互

提问：表单字段多了以后 Prompt 会很长，怎么组织才能让 AI 不漏东西？回答：用结构化格式来组织，比如 Markdown 表格或者 YAML 风格的缩进。每个字段单独一个 block，里面包含名称、类型、必填性、校验规则、错误提示。AI 对结构化数据的理解能力比纯文本强很多，漏东西的概率会低不少。另外可以在末尾加一句”请确认你理解了所有 N 个字段的要求后再生成代码”，让 AI 先复述一遍需求。- 提问：如果验证逻辑很复杂，比如字段之间有联动关系，Prompt 该怎么写？
回答：联动关系要单独拎出来写清楚，不要混在字段定义里。比如”当用户类型选择企业时，公司名称和营业执照号变成必填”，这种就单独一段描述。还可以用伪代码或者流程图来表达，比如”if userType === ‘company’ then companyName.required = true”。越复杂的逻辑越要写得明确，别指望 AI 能猜出你的意图。- 提问：生成的代码跑起来有 bug，怎么通过改 Prompt 来修而不是自己手动改？
回答：把 bug 现象描述清楚喂回去。比如”你生成的代码在确认密码字段校验时有问题，当密码字段清空后再填确认密码，校验不会触发。请修复这个问题，确保密码字段变化时会重新校验确认密码字段”。本质上就是把你 debug 的思路用自然语言写出来。如果 bug 很隐蔽，可以把出问题的代码段贴回去，让 AI 重点看那一块。- 提问：React Hook Form 和 Formik 你更推荐哪个？为什么？
回答：现在新项目肯定选 React Hook Form。性能上，React Hook Form 是非受控组件，重渲染次数少很多，官方 benchmark 显示能快 2-3 倍。体积上，React Hook Form 压缩后 8KB，Formik 要 12KB。API 上，React Hook Form 的 register 比 Formik 的 Field 组件更简洁。唯一 Formik 还有点优势的是社区资料多一些，毕竟出来得早，但 React Hook Form 现在文档也很完善了，上手不难。

为什么用 React Hook Form 而不是受控组件验证库选型对比写 Prompt 容易忽略的坑分步生成 vs 一次性生成

来源: 假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）.mhtml

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）#

- 一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。
- 直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
本文已做格式统一与噪声清理，保留原始语义。
假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）#
1. 假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）VIP中等大模型标记分享31022面试问答让大模型生成一个能直接用的 React 表单组件，Prompt 得把上下文约束写死，不然 AI 就会按自己的理解乱发挥。一个完整的 Prompt 应该覆盖四个维度：字段定义、验证规则、交互行为、代码规范。直接上一个实战级的 Prompt 示例：▼plaintext复制代码用 React 18 + TypeScript + React Hook Form 写一个用户注册表单组件。
- 用户名：必填，2-10 个字符，只能包含字母数字下划线
- 邮箱：必填，标准邮箱格式
- 密码：必填，8-20 位，至少包含一个大写、一个小写、一个数字
本文已做格式统一与噪声清理，保留原始语义。

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？整理

Wed, 10 Jun 2026 00:00:00 GMT

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？#

问题#

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？

标准回答#

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？VIP中等AI大模型RAG向量数据库标记分享211328面试问答向量搜索的核心就是衡量两个向量有多”像”，三种方法各有侧重：余弦相似度只看方向不看长度，两个向量夹角越小、值越接近 1，说明方向越一致。文本向量检索基本都用它，因为我们关心的是语义方向，一篇 100 字的文章和一篇 1000 字的文章只要讲的是同一个主题，余弦相似度就会很高。取值范围 -1 到 1，1 是完全同向，-1 是完全反向。欧几里得距离算的是空间中两点之间的直线距离，就是勾股定理那一套。图像检索、人脸识别这类场景用得多，因为像素特征向量本身就有”绝对位置”的含义，两张图的特征向量在空间里离得越近，长得就越像。取值 ≥ 0，越小越相似。曼哈顿距离把各维度的差值绝对值加起来，像在城市街区里沿着街道走，不能斜着穿。网格数据、稀疏特征向量用得比较多，比如地图坐标计算、高维稀疏文本特征。取值 ≥ 0，同样越小越相似。三种方法的选型逻辑：文本、推荐系统首选余弦相似度；图像、视频检索首选欧氏距离；网格坐标、稀疏高维数据考虑曼哈顿距离。

扩展知识#

数学公式与计算复杂度假设有两个 n 维向量 A 和 B：1）余弦相似度的公式是两个向量的点积除以模长的乘积，计算量主要是 n 次乘法加 n 次加法，再算两个模长。Faiss、Milvus 这类向量数据库内部会对归一化后的向量做优化，归一化之后余弦相似度就等价于点积，省掉模长计算。

2）欧氏距离是各维度差值平方和再开根号。实际检索时经常省掉开根号这一步，直接比较平方和就够了，能省不少计算。

3）曼哈顿距离是各维度差值绝对值之和，计算最简单，没有乘法和开方，在高维稀疏场景下效率有优势。三种距离的计算过程对比：余弦相似度：先算点积 A·B，再算 |A| 和 |B|，最后做除法

欧氏距离：逐维度算差值、平方、累加，最后开根号

曼哈顿距离：逐维度算差值、取绝对值、累加不同场景的选型考量文本语义检索基本锁定余弦相似度，原因很直接：Embedding 模型输出的向量长度本身没有业务含义，一个句子长一点短一点不影响语义，我们只关心向量指向哪个方向。OpenAI 的 text-embedding-ada-002、BGE、M3E 这些模型出来的向量都建议用余弦相似度。图像检索更适合欧氏距离，ResNet、CLIP 这类视觉模型提取的特征向量，其数值大小本身携带了像素强度、纹理密度这些信息。人脸识别领域的 ArcFace、CosFace 虽然名字里带 Cos，但训练时用的是角度 margin，推理时用欧氏距离效果更稳定。曼哈顿距离在推荐系统的用户行为特征上有奇效，用户点击、购买这类行为天然是 0/1 稀疏向量，曼哈顿距离对这种数据不敏感于个别维度的极端值，鲁棒性比欧氏距离好。向量数据库的索引加速不管用哪种距离度量，暴力遍历 1 亿条向量肯定扛不住，所以向量数据库都会建索引。主流的索引算法：1）IVF 系列：先把向量空间切成 1000-10000 个聚类中心，查询时只在最近的几个聚类里找，Milvus、Faiss 都支持。

2） HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确，Pinecone、Qdrant 默认都用这个。

3） PQ 量化：把 128 维向量切成 8 个子空间，每个子空间量化成 256 个码本，空间压缩 32 倍，精度损失可控。这些索引算法和距离度量是正交的，IVF 搭余弦、HNSW 搭欧氏都行，只要在建索引和查询时保持一致就没问题。实际踩坑经验1）向量没归一化就用余弦相似度，结果会很诡异。有些 Embedding 模型输出的向量本身不是单位向量，得自己先 L2 归一化再存进向量库。

2）欧氏距离对数值尺度敏感，如果某几个维度的数值特别大，会把距离带偏。工业界常见做法是先做 z-score 标准化，让各维度方差一致。

3）高维空间有”维度灾难”，当维度超过几百维，所有向量之间的距离都趋于相等，区分度变差。这时候降维或者换用近似算法比纠结用哪种距离更重要。

维基百科余弦相似度维基百科欧几里得距离维基百科曼哈顿距离

面试官追问#

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？回答：归一化之后所有向量的模长都是 1，欧氏距离的平方展开是 |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者是单调递减关系，排序结果完全一致。所以很多向量库内部会强制归一化，统一用点积来算，还能利用 SIMD 指令加速。- 提问：为什么说曼哈顿距离对高维稀疏数据更友好？
回答：稀疏向量里大部分维度都是 0，有值的维度可能差异很大。欧氏距离会把大差异平方放大，一个维度差 10 就贡献 100；曼哈顿距离只是线性累加，差 10 就贡献 10。这样少数几个极端维度不会主导整体距离，对稀疏数据更稳定。- 提问：实际业务中怎么选向量搜索的距离度量？
回答：先看 Embedding 模型官方推荐，大多数文本模型都建议余弦相似度。如果是自己训练的模型，就看训练时 loss 函数用的什么度量，推理时保持一致。实在拿不准就跑个 A/B 测试，用业务指标说话，别凭感觉猜。

数学公式与计算复杂度不同场景的选型考量向量数据库的索引加速实际踩坑经验

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？提问：为什么说曼哈顿距离对高维稀疏数据更友好？提问：实际业务中怎么选向量搜索的距离度量？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

Copilot 模式和 Agent 模式的区别是什么？上次浏览：2026-03-16 14:49:50什么是向量数据库？在基于大模型的应用开发中，向量数据库主要解决什么问题？你都了解哪些向量数据库？如何选型？上次浏览：2026-03-16 14:50:03向量数据库原理是什么？请简述下它的原理上次浏览：2026-03-16 14:50:13向量数据库中的 HNSW、LSH、PQ 分别是什么意思？向量数据库中的 ANN 是什么？为什么需要用它？向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？向量数据库的工作流程有哪些？请简述下什么是 MCP 协议，它在 AI 大模型系统中的作用是什么？上次浏览：2026-03-16 14:50:33MCP 架构包含哪些核心组件？上次浏览：2026-03-16 14:51:22MCP 协议支持哪两种模式？上次浏览：2026-03-16 14:51:4211595. 向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？VIP中等AI大模型RAG向量数据库标记分享211328面试问答向量搜索的核心就是衡量两个向量有多”像”，三种方法各有侧重：余弦相似度只看方向不看长度，两个向量夹角越小、值越接近 1，说明方向越一致。文本向量检索基本都用它，因为我们关心的是语义方向，一篇 100 字的文章和一篇 1000 字的文章只要讲的是同一个主题，余弦相似度就会很高。取值范围 -1 到 1，1 是完全同向，-1 是完全反向。欧几里得距离算的是空间中两点之间的直线距离，就是勾股定理那一套。图像检索、人脸识别这类场景用得多，因为像素特征向量本身就有”绝对位置”的含义，两张图的特征向量在空间里离得越近，长得就越像。取值 ≥ 0，越小越相似。曼哈顿距离把各维度的差值绝对值加起来，像在城市街区里沿着街道走，不能斜着穿。网格数据、稀疏特征向量用得比较多，比如地图坐标计算、高维稀疏文本特征。取值 ≥ 0，同样越小越相似。三种方法的选型逻辑：文本、推荐系统首选余弦相似度；图像、视频检索首选欧氏距离；网格坐标、稀疏高维数据考虑曼哈顿距离。

2）欧氏距离是各维度差值平方和再开根号。实际检索时经常省掉开根号这一步，直接比较平方和就够了，能省不少计算。

欧氏距离：逐维度算差值、平方、累加，最后开根号

2） HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确，Pinecone、Qdrant 默认都用这个。

2）欧氏距离对数值尺度敏感，如果某几个维度的数值特别大，会把距离带偏。工业界常见做法是先做 z-score 标准化，让各维度方差一致。

维基百科余弦相似度维基百科欧几里得距离维基百科曼哈顿距离

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？回答：归一化之后所有向量的模长都是 1，欧氏距离的平方展开是 |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者是单调递减关系，排序结果完全一致。所以很多向量库内部会强制归一化，统一用点积来算，还能利用 SIMD 指令加速。- 提问：为什么说曼哈顿距离对高维稀疏数据更友好？
回答：稀疏向量里大部分维度都是 0，有值的维度可能差异很大。欧氏距离会把大差异平方放大，一个维度差 10 就贡献 100；曼哈顿距离只是线性累加，差 10 就贡献 10。这样少数几个极端维度不会主导整体距离，对稀疏数据更稳定。- 提问：实际业务中怎么选向量搜索的距离度量？
回答：先看 Embedding 模型官方推荐，大多数文本模型都建议余弦相似度。如果是自己训练的模型，就看训练时 loss 函数用的什么度量，推理时保持一致。实在拿不准就跑个 A/B 测试，用业务指标说话，别凭感觉猜。

数学公式与计算复杂度不同场景的选型考量向量数据库的索引加速实际踩坑经验

来源: 向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？.mhtml

关键点#

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？#
有什么区别？
问题#

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？

有什么区别？
VIP中等AI大模型RAG向量数据库标记分享211328面试问答向量搜索的核心就是衡量两个向量有多”像”，三种方法各有侧重：余弦相似度只看方向不看长度，两个向量夹角越小、值越接近 1，说明方向越一致。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？

标准回答#
问题#

2）欧氏距离是各维度差值平方和再开根号。实际检索时经常省掉开根号这一步，直接比较平方和就够了，能省不少计算。

欧氏距离：逐维度算差值、平方、累加，最后开根号

2） HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确，Pinecone、Qdrant 默认都用这个。

2）欧氏距离对数值尺度敏感，如果某几个维度的数值特别大，会把距离带偏。工业界常见做法是先做 z-score 标准化，让各维度方差一致。

维基百科余弦相似度维基百科欧几里得距离维基百科曼哈顿距离

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？回答：归一化之后所有向量的模长都是 1，欧氏距离的平方展开是 |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者是单调递减关系，排序结果完全一致。所以很多向量库内部会强制归一化，统一用点积来算，还能利用 SIMD 指令加速。- 提问：为什么说曼哈顿距离对高维稀疏数据更友好？
回答：稀疏向量里大部分维度都是 0，有值的维度可能差异很大。欧氏距离会把大差异平方放大，一个维度差 10 就贡献 100；曼哈顿距离只是线性累加，差 10 就贡献 10。这样少数几个极端维度不会主导整体距离，对稀疏数据更稳定。- 提问：实际业务中怎么选向量搜索的距离度量？
回答：先看 Embedding 模型官方推荐，大多数文本模型都建议余弦相似度。如果是自己训练的模型，就看训练时 loss 函数用的什么度量，推理时保持一致。实在拿不准就跑个 A/B 测试，用业务指标说话，别凭感觉猜。

数学公式与计算复杂度不同场景的选型考量向量数据库的索引加速实际踩坑经验

Copilot 模式和 Agent 模式的区别是什么？上次浏览：2026-03-16 14:49:50什么是向量数据库？在基于大模型的应用开发中，向量数据库主要解决什么问题？你都了解哪些向量数据库？如何选型？上次浏览：2026-03-16 14:50:03向量数据库原理是什么？

请简述下它的原理上次浏览：2026-03-16 14:50:13向量数据库中的 HNSW、LSH、PQ 分别是什么意思？向量数据库中的 ANN 是什么？为什么需要用它？向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？向量数据库的工作流程有哪些？请简述下什么是 MCP 协议，它在 AI 大模型系统中的作用是什么？上次浏览：2026-03-16 14:50:33MCP 架构包含哪些核心组件？上次浏览：2026-03-16 14:51:22MCP 协议支持哪两种模式？上次浏览：2026-03-16 14:51:4211595. 向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？VIP中等AI大模型RAG向量数据库标记分享211328面试问答向量搜索的核心就是衡量两个向量有多”像”，三种方法各有侧重：余弦相似度只看方向不看长度，两个向量夹角越小、值越接近 1，说明方向越一致。文本向量检索基本都用它，因为我们关心的是语义方向，一篇 100 字的文章和一篇 1000 字的文章只要讲的是同一个主题，余弦相似度就会很高。取值范围 -1 到 1，1 是完全同向，-1 是完全反向。欧几里得距离算的是空间中两点之间的直线距离，就是勾股定理那一套。图像检索、人脸识别这类场景用得多，因为像素特征向量本身就有”绝对位置”的含义，两张图的特征向量在空间里离得越近，长得就越像。取值 ≥ 0，越小越相似。曼哈顿距离把各维度的差值绝对值加起来，像在城市街区里沿着街道走，不能斜着穿。网格数据、稀疏特征向量用得比较多，比如地图坐标计算、高维稀疏文本特征。取值 ≥ 0，同样越小越相似。三种方法的选型逻辑：文本、推荐系统首选余弦相似度；图像、视频检索首选欧氏距离；网格坐标、稀疏高维数据考虑曼哈顿距离。

2）欧氏距离是各维度差值平方和再开根号。实际检索时经常省掉开根号这一步，直接比较平方和就够了，能省不少计算。

欧氏距离：逐维度算差值、平方、累加，最后开根号

2） HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确，Pinecone、Qdrant 默认都用这个。

2）欧氏距离对数值尺度敏感，如果某几个维度的数值特别大，会把距离带偏。工业界常见做法是先做 z-score 标准化，让各维度方差一致。

维基百科余弦相似度维基百科欧几里得距离维基百科曼哈顿距离

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？回答：归一化之后所有向量的模长都是 1，欧氏距离的平方展开是 |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者是单调递减关系，排序结果完全一致。所以很多向量库内部会强制归一化，统一用点积来算，还能利用 SIMD 指令加速。- 提问：为什么说曼哈顿距离对高维稀疏数据更友好？
回答：稀疏向量里大部分维度都是 0，有值的维度可能差异很大。欧氏距离会把大差异平方放大，一个维度差 10 就贡献 100；曼哈顿距离只是线性累加，差 10 就贡献 10。这样少数几个极端维度不会主导整体距离，对稀疏数据更稳定。- 提问：实际业务中怎么选向量搜索的距离度量？
回答：先看 Embedding 模型官方推荐，大多数文本模型都建议余弦相似度。如果是自己训练的模型，就看训练时 loss 函数用的什么度量，推理时保持一致。实在拿不准就跑个 A/B 测试，用业务指标说话，别凭感觉猜。

数学公式与计算复杂度不同场景的选型考量向量数据库的索引加速实际踩坑经验

来源: 向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？.mhtml

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？#
- 有什么区别？
本文已做格式统一与噪声清理，保留原始语义。
向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？
向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？#
1. 向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？VIP中等AI大模型RAG向量数据库标记分享211328面试问答向量搜索的核心就是衡量两个向量有多”像”，三种方法各有侧重：余弦相似度只看方向不看长度，两个向量夹角越小、值越接近 1，说明方向越一致。文本向量检索基本都用它，因为我们关心的是语义方向，一篇 100 字的文章和一篇 1000 字的文章只要讲的是同一个主题，余弦相似度就会很高。取值范围 -1 到 1，1 是完全同向，-1 是完全反向。欧几里得距离算的是空间中两点之间的直线距离，就是勾股定理那一套。图像检索、人脸识别这类场景用得多，因为像素特征向量本身就有”绝对位置”的含义，两张图的特征向量在空间里离得越近，长得就越像。取值 ≥ 0，越小越相似。曼哈顿距离把各维度的差值绝对值加起来，像在城市街区里沿着街道走，不能斜着穿。网格数据、稀疏特征向量用得比较多，比如地图坐标计算、高维稀疏文本特征。取值 ≥ 0，同样越小越相似。三种方法的选型逻辑：文本、推荐系统首选余弦相似度；图像、视频检索首选欧氏距离；网格坐标、稀疏高维数据考虑曼哈顿距离。

2）欧氏距离是各维度差值平方和再开根号。实际检索时经常省掉开根号这一步，直接比较平方和就够了，能省不少计算。

欧氏距离：逐维度算差值、平方、累加，最后开根号
曼哈顿距离：逐维度算差值、取绝对值、累加不同场景的选型考量文本语义检索基本锁定余弦相似度，原因很直接：Embedding 模型输出的向量长度本身没有业务含义，一个句子长一点短一点不影响语义，我们只关心向量指向哪个方向。OpenAI 的 text-embedding-ada-002、BGE、M3E 这些模型出来的向量都建议用余弦相似度。图像检索更适合欧氏距离，ResNet、CLIP 这类视觉模型提取的特征向量，其数值大小本身携带了像素强度、纹理密度这些信息。人脸识别领域的 ArcFace、CosFace 虽然名字里带 Cos，但训练时用的是角度 margin，推理时用欧氏距离效果更稳定。曼哈顿距离在推荐系统的用户行为特征上有奇效，用户点击、购买这类行为天然是 0/1 稀疏向量，曼哈顿距离对这种数据不敏感于个别维度的极端值，鲁棒性比欧氏距离好。向量数据库的索引加速不管用哪种距离度量，暴力遍历 1 亿条向量肯定扛不住，所以向量数据库都会建索引。主流的索引算法：1）IVF 系列：先把向量空间切成 1000-10000 个聚类中心，查询时只在最近的几个聚类里找，Milvus、Faiss 都支持。

2） HNSW：构建多层图结构，高层稀疏跳跃、低层密集精确，Pinecone、Qdrant 默认都用这个。

2）欧氏距离对数值尺度敏感，如果某几个维度的数值特别大，会把距离带偏。工业界常见做法是先做 z-score 标准化，让各维度方差一致。

维基百科余弦相似度维基百科欧几里得距离维基百科曼哈顿距离

提问：余弦相似度和欧氏距离在归一化向量上是等价的，能解释一下为什么吗？回答：归一化之后所有向量的模长都是 1，欧氏距离的平方展开是 |A|² + |B|² - 2A·B = 2 - 2A·B，而余弦相似度就是 A·B。两者是单调递减关系，排序结果完全一致。所以很多向量库内部会强制归一化，统一用点积来算，还能利用 SIMD 指令加速。- 提问：为什么说曼哈顿距离对高维稀疏数据更友好？
回答：稀疏向量里大部分维度都是 0，有值的维度可能差异很大。欧氏距离会把大差异平方放大，一个维度差 10 就贡献 100；曼哈顿距离只是线性累加，差 10 就贡献 10。这样少数几个极端维度不会主导整体距离，对稀疏数据更稳定。- 提问：实际业务中怎么选向量搜索的距离度量？
回答：先看 Embedding 模型官方推荐，大多数文本模型都建议余弦相似度。如果是自己训练的模型，就看训练时 loss 函数用的什么度量，推理时保持一致。实在拿不准就跑个 A/B 测试，用业务指标说话，别凭感觉猜。

数学公式与计算复杂度不同场景的选型考量向量数据库的索引加速实际踩坑经验

本文已做格式统一与噪声清理，保留原始语义。

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？整理

Wed, 10 Jun 2026 00:00:00 GMT

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？#

问题#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

标准回答#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？VIP中等AI大模型RAG标记分享302576面试问答选择 Embedding Model 核心看7 个因素，可以概括为”准、快、专、广、大、活、省”：1）准，语义准确性。模型能不能精准捕捉文本语义，长句理解、上下文关联、同义词区分这些能力直接影响向量相似度计算的可靠性2）快，模型效率。推理速度能不能满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源3）专，领域适配。是不是针对垂直领域做过预训练或微调，金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材4）广，多语言支持。是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能不能正确嵌入5）大，数据规模匹配。模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩6）活，开放性与生态。是否开源、社区是否活跃、能不能定制化微调，API 调用是否灵活7）省，成本。计算成本包括训练推理的硬件投入，使用成本包括第三方 API 的 token 费用和商用授权费

扩展知识#

语义准确性怎么评估这是模型的理解基本功，通常用语义相似度任务来评估，比如 STS-B 数据集，看模型对同义句和反义句的向量距离是否合理。需要注意两点：一是部分模型擅长短文本，像 Sentence-BERT 处理长文本时会丢失上下文，这种情况得选 RoBERTa 变种或 Longformer 类模型；二是通用模型在专业领域可能词不达意，比如”主诉”在医疗文本中是专有名词，通用模型可能理解成”主要诉求”。模型效率的权衡领域适配的三种策略让模型懂行话有三种常见策略：1）直接选领域专用模型，LegalBERT 用于法律文档，PubMedBERT 用于医学文献2）用通用模型加领域数据微调，适合有私有语料的场景，比如用公司内部客服对话数据微调3）添加领域适配器，用 LoRA 技术在不改变原模型的前提下新增少量参数适配领域有个真实案例：某电商场景的 RAG 用通用模型时，“SKU”、“客单价”这些词嵌入效果很差，切换到零售领域预训练的模型后，召回准确率提升了 23%。多语言支持单语言模型像 Chinese-BERT 只支持中文，XLM-RoBERTa 支持 100 多种语言但需要分别处理。跨语言模型像 mBERT 基于双语对齐训练，中英句子嵌入在同一空间，适合翻译场景。小语种比如斯瓦希里语可能没有专用模型，这时候得用通用多语言模型加数据增强，比如用 Google 的 multilingual T5 模型配合少量目标语言语料微调。开源和闭源的选择开源模型像 Sentence-BERT 可以灵活修改代码，适合深度定制，比如加入自定义分词器，但需要自己解决部署和优化问题。闭源 API 像 OpenAI Embedding、Cohere 开箱即用，适合快速验证 MVP，但受限于厂商更新和费用，OpenAI 按 token 收费，长文本成本比较高。相关文档与扩展阅读链接Hugging Face 官方 Embedding 模型合集：Hugging Face Embedding Models11549. 在 RAG 中，你知道有哪些 Embedding Model 嵌入模型？

面试官追问#

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？回答：可以用级联策略。第一阶段用轻量模型快速召回 Top 100，MiniLM 这种毫秒级就能出结果。第二阶段用重型模型对这 100 条做精排，BERT-large 处理 100 条也就几百毫秒。这样既保证了响应速度，又不损失最终的语义准确性。另外可以考虑模型蒸馏，用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。- 提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？
回答：最靠谱的方式是构建评测数据集。从业务数据里挑 500 到 1000 条 query，人工标注相关文档，然后用 Recall@K、MRR 这些指标来评估召回效果。不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和你的业务数据分布可能差很远。另外可以做 A/B 测试，看用户的点击率和满意度有没有提升。- 提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？
回答：可以试几个方案。一是用 LoRA 这种参数高效微调技术，几千条数据就能有效果，训练成本也低。二是用数据增强，把现有数据用大模型改写扩充，或者用同义词替换、回译等方式扩大数据量。三是构建领域词表做预处理，把专业术语替换成通用模型能理解的描述，检索完再还原回来。 ① 开源模型，比如 BGE、M3E、Sentence Transformers、E5、GTE；

② 商业 embedding，比如 OpenAI text-embedding-3、Cohere、Google Gecko；

③ 大模型自带的向量接口展开新页面打开2025-11-18 16:5300回复NULL准快专广大活省准：大模型能否精确提取文档中重要信息快：向量转换速度专：是否有对不同的领域进行术语调整广：适配多语言大：语义和数据规模是否匹配活：相关社区或技术是否更新快展开新页面打开2025-08-23 03:1900回复晚夜微雨问海棠特训营在 RAG 系统中选择 Embedding 模型需综合考量以下核心要素，形成系统性决策框架：一、任务需求维度语义粒度短句匹配（如问答对）→ 选择擅长句子级嵌入的模型（如all-MiniLM-L6-v2）长文档检索展开新页面打开2025-04-22 14:1400回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

语义准确性怎么评估模型效率的权衡领域适配的三种策略多语言支持开源和闭源的选择相关文档与扩展阅读链接

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

什么是 RAG 中的分块？为什么需要分块？在 RAG 中，常见的分块策略有哪些？分别有什么区别？在 RAG 中的 Embedding 嵌入是什么？在 RAG 中，你知道有哪些 Embedding Model 嵌入模型？上次浏览：2026-03-16 11:41:28在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？在 RAG 中，索引流程中的文档解析你们怎么做的？在 RAG 应用的过程中，关于提示工程的设计有什么心得和技巧吗？上次浏览：2026-03-16 11:41:50什么是 Advanced RAG？上次浏览：2026-03-16 11:42:17什么是 Modular RAG？上次浏览：2026-03-16 11:42:40什么是护栏技术？上次浏览：2026-03-16 11:42:49什么是 GPTCache？上次浏览：2026-03-16 11:43:3511550. 在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？VIP中等AI大模型RAG标记分享302576面试问答选择 Embedding Model 核心看7 个因素，可以概括为”准、快、专、广、大、活、省”：1）准，语义准确性。模型能不能精准捕捉文本语义，长句理解、上下文关联、同义词区分这些能力直接影响向量相似度计算的可靠性2）快，模型效率。推理速度能不能满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源3）专，领域适配。是不是针对垂直领域做过预训练或微调，金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材4）广，多语言支持。是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能不能正确嵌入5）大，数据规模匹配。模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩6）活，开放性与生态。是否开源、社区是否活跃、能不能定制化微调，API 调用是否灵活7）省，成本。计算成本包括训练推理的硬件投入，使用成本包括第三方 API 的 token 费用和商用授权费

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？回答：可以用级联策略。第一阶段用轻量模型快速召回 Top 100，MiniLM 这种毫秒级就能出结果。第二阶段用重型模型对这 100 条做精排，BERT-large 处理 100 条也就几百毫秒。这样既保证了响应速度，又不损失最终的语义准确性。另外可以考虑模型蒸馏，用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。- 提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？
回答：最靠谱的方式是构建评测数据集。从业务数据里挑 500 到 1000 条 query，人工标注相关文档，然后用 Recall@K、MRR 这些指标来评估召回效果。不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和你的业务数据分布可能差很远。另外可以做 A/B 测试，看用户的点击率和满意度有没有提升。- 提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？
回答：可以试几个方案。一是用 LoRA 这种参数高效微调技术，几千条数据就能有效果，训练成本也低。二是用数据增强，把现有数据用大模型改写扩充，或者用同义词替换、回译等方式扩大数据量。三是构建领域词表做预处理，把专业术语替换成通用模型能理解的描述，检索完再还原回来。 ① 开源模型，比如 BGE、M3E、Sentence Transformers、E5、GTE；

② 商业 embedding，比如 OpenAI text-embedding-3、Cohere、Google Gecko；

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

语义准确性怎么评估模型效率的权衡领域适配的三种策略多语言支持开源和闭源的选择相关文档与扩展阅读链接

来源: 在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？.mhtml

关键点#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？#
问题#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

VIP中等AI大模型RAG标记分享302576面试问答选择 Embedding Model 核心看7 个因素，可以概括为”准、快、专、广、大、活、省”：1）准，语义准确性。
模型能不能精准捕捉文本语义，长句理解、上下文关联、同义词区分这些能力直接影响向量相似度计算的可靠性2）快，模型效率。
推理速度能不能满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源3）专，领域适配。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

标准回答#
问题#

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？回答：可以用级联策略。第一阶段用轻量模型快速召回 Top 100，MiniLM 这种毫秒级就能出结果。第二阶段用重型模型对这 100 条做精排，BERT-large 处理 100 条也就几百毫秒。这样既保证了响应速度，又不损失最终的语义准确性。另外可以考虑模型蒸馏，用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。- 提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？
回答：最靠谱的方式是构建评测数据集。从业务数据里挑 500 到 1000 条 query，人工标注相关文档，然后用 Recall@K、MRR 这些指标来评估召回效果。不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和你的业务数据分布可能差很远。另外可以做 A/B 测试，看用户的点击率和满意度有没有提升。- 提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？
回答：可以试几个方案。一是用 LoRA 这种参数高效微调技术，几千条数据就能有效果，训练成本也低。二是用数据增强，把现有数据用大模型改写扩充，或者用同义词替换、回译等方式扩大数据量。三是构建领域词表做预处理，把专业术语替换成通用模型能理解的描述，检索完再还原回来。 ① 开源模型，比如 BGE、M3E、Sentence Transformers、E5、GTE；

② 商业 embedding，比如 OpenAI text-embedding-3、Cohere、Google Gecko；

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

语义准确性怎么评估模型效率的权衡领域适配的三种策略多语言支持开源和闭源的选择相关文档与扩展阅读链接

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？回答：可以用级联策略。第一阶段用轻量模型快速召回 Top 100，MiniLM 这种毫秒级就能出结果。第二阶段用重型模型对这 100 条做精排，BERT-large 处理 100 条也就几百毫秒。这样既保证了响应速度，又不损失最终的语义准确性。另外可以考虑模型蒸馏，用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。- 提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？
回答：最靠谱的方式是构建评测数据集。从业务数据里挑 500 到 1000 条 query，人工标注相关文档，然后用 Recall@K、MRR 这些指标来评估召回效果。不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和你的业务数据分布可能差很远。另外可以做 A/B 测试，看用户的点击率和满意度有没有提升。- 提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？
回答：可以试几个方案。一是用 LoRA 这种参数高效微调技术，几千条数据就能有效果，训练成本也低。二是用数据增强，把现有数据用大模型改写扩充，或者用同义词替换、回译等方式扩大数据量。三是构建领域词表做预处理，把专业术语替换成通用模型能理解的描述，检索完再还原回来。 ① 开源模型，比如 BGE、M3E、Sentence Transformers、E5、GTE；

② 商业 embedding，比如 OpenAI text-embedding-3、Cohere、Google Gecko；

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

语义准确性怎么评估模型效率的权衡领域适配的三种策略多语言支持开源和闭源的选择相关文档与扩展阅读链接

来源: 在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？.mhtml

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？#
- 问题#

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

- VIP中等AI大模型RAG标记分享302576面试问答选择 Embedding Model 核心看7 个因素，可以概括为”准、快、专、广、大、活、省”：1）准，语义准确性。
本文已做格式统一与噪声清理，保留原始语义。
在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？
在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？#
1. 在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？VIP中等AI大模型RAG标记分享302576面试问答选择 Embedding Model 核心看7 个因素，可以概括为”准、快、专、广、大、活、省”：1）准，语义准确性。模型能不能精准捕捉文本语义，长句理解、上下文关联、同义词区分这些能力直接影响向量相似度计算的可靠性2）快，模型效率。推理速度能不能满足业务实时性要求，QPS 高的场景不能用太大的模型，显存占用也得适配硬件资源3）专，领域适配。是不是针对垂直领域做过预训练或微调，金融模型懂”PE 估值”是市盈率，通用模型可能理解成体育器材4）广，多语言支持。是否支持业务所需语言，跨语言对齐能力怎么样，中英混合文本能不能正确嵌入5）大，数据规模匹配。模型参数量和训练数据规模要匹配语料复杂度，小数据用大模型容易过拟合，大数据用小模型会出现语义坍缩6）活，开放性与生态。是否开源、社区是否活跃、能不能定制化微调，API 调用是否灵活7）省，成本。计算成本包括训练推理的硬件投入，使用成本包括第三方 API 的 token 费用和商用授权费

提问：如果线上 QPS 很高，但又想保证语义准确性，怎么平衡？回答：可以用级联策略。第一阶段用轻量模型快速召回 Top 100，MiniLM 这种毫秒级就能出结果。第二阶段用重型模型对这 100 条做精排，BERT-large 处理 100 条也就几百毫秒。这样既保证了响应速度，又不损失最终的语义准确性。另外可以考虑模型蒸馏，用大模型的输出去训练小模型，让小模型在特定场景下接近大模型效果。- 提问：怎么判断一个嵌入模型在你的业务场景下效果好不好？
回答：最靠谱的方式是构建评测数据集。从业务数据里挑 500 到 1000 条 query，人工标注相关文档，然后用 Recall@K、MRR 这些指标来评估召回效果。不能只看 MTEB 榜单排名，因为榜单用的是通用数据集，和你的业务数据分布可能差很远。另外可以做 A/B 测试，看用户的点击率和满意度有没有提升。- 提问：公司内部文档很多专业术语，通用模型效果差，但又没有足够数据微调，怎么办？
回答：可以试几个方案。一是用 LoRA 这种参数高效微调技术，几千条数据就能有效果，训练成本也低。二是用数据增强，把现有数据用大模型改写扩充，或者用同义词替换、回译等方式扩大数据量。三是构建领域词表做预处理，把专业术语替换成通用模型能理解的描述，检索完再还原回来。- ① 开源模型，比如 BGE、M3E、Sentence Transformers、E5、GTE；
② 商业 embedding，比如 OpenAI text-embedding-3、Cohere、Google Gecko；
本文已做格式统一与噪声清理，保留原始语义。

如何找到第一份agent实习项目分享

Wed, 10 Jun 2026 00:00:00 GMT

各位大家在關注或者在寻找Agent開發後段開發或者全戰開發的小夥伴們大家好今天我就在這裡就進行一期對一個人在最近兩個月早熟期時期最後可力無收到最後短暫寫到一個小場出場的一個短暫時期最終拿到Over的一系經驗分享不要包括幾個部分所謂是個人的背景我的熟期時期的一些經歷最後是項目的方面介紹一下個人的項目情況還有一些用AI幫助我做的事情最後就是相關聯結昨天主播就是一個一名耳其界的中上九本科生個人是三個零零是些零比三零零然後在書記時期的時候我也是拿到一些大場比如騰訊之間美團、螞蟻這些大型企業的緣面的都是有一些中場比如中按Opo等等一些小場的情況大家可以看一下我的時間中我是從大概三月中旬開始脫地的最終是3月23號的第一場面是電給自己那大師主播我已經會準備得非常不同分直接贏得脫皮上結果就靠大麻了所以也是三進攻最後全都到在一面大概是從5月中旬的時候我就用我後面優化後新改了一個AI項目開始進行面試這種時候到了出場的Offer 還有Opo到了HR面但是可能HR面後面掛了我介紹一下個人的項目情況我就是一個後端的高比方項目加一個AI項目這個後端項目的話就是一個支持星球上的當時花錢買的項目所以就不放出來建立了但是我感覺那個項目有點太難了我還得自己給它變簡單了一點加起來其實大家直接用HMR點皮加做一些優化感覺是OK的可以給大家看一下我舊項目的剪例是怎麼寫的畢竟我之前那些大廠的項目也是剛好舊項目吃月到的首先肯定是有一些寫到好的地方第一點我感覺就是我的格式和結構我之前是前面黑底字的一些改革加上帽號後面是詳細的描述第二點可能就是就這些數字的變化會從原來一個比較差的指標然後後面得到一個更良好的指標為什麼說這些數字的變化很重要因為你又試著就意味著你要做側瓶覺得做項目比較重要的感覺就是有這種側瓶思維還有壁環的思維因為你就壁環了才是完整流程意味著你這個項目才是可以跌代的可以優化的也是可以反映出你個人的優化的思維我們大概不僅內容有拉格它的大概流程即方面的設計 Agent工作流這個工作流就是這種拉掛伏裡面的那個節點可以實現然後就是工具然後模型優化這一個當時是我趴自己的項目亮點太少強行要加了一個我説大概是我的項目某一個環節那應該是評審那環節可能太厚實了我就想給它做一個效應的項目微調一下看它們接受了一些時間降低延遲好的就先談一談為什麼我從一個拉格項目最後換了一個項目變成了一個mini boat 只能提項目然後它第一點你用項目假設你做那個拉格項目放上去你的便宜式觀彈一連要可能回外圖就我們先需要瞭解到拉格它其實在工業上是用來處理達到可能前往跟兩級的即使如果你是那種比較即使個 300個的溫當的話應該是沒有必要上拉格的假設我會答我是為了解解決生活中的需求比如說這裡我的筆記但它的筆記數量可能達不到那麼多就可能不算一個應用場景那你假如說我找做一個醫療入手或者是金融入手就是會放一些比如說公開的數據進去但現在的在一個方面現在 A3也可以進行電網搜索如果有電網搜索功能之後我直接上網去搜因為都是公開的資料除非你是4人的文道公開資料你就是拉格進行處理跟直接進行搜索它的效果對比要證明拉格的效果要比這個連搜索也更好這可能是需要一些數據的職程的我問你說我是為了學習使用我要學習一下AI 我就做了一個拉格那我感覺也是不太好的理由因為AI的方便我覺得是一個一直在追溯勒典的這樣一個方向因為它的技術跌代是非常快的大概可能兩三個月我就會突然冒出一些新的技術那這個拉格它其實是2024年的兩三年前比較火的技術那你說我學AI 我用這個來進行學可能會讓密室官覺得你對這是新技術的好幾何探索不住第二個理由就是對主拉格你要對它有非常多的數據你要對它就是一些掌握要大概了解你怎麼得到一些對家的選擇比如說拉格裡面它有切塊切塊大橋的選擇還有評測數據指標的選擇然後那個 Invading的模型的選擇可能是需要你執行很多組的AB測試來得到這種答案還有密室官可能會問你一些比如說你這個技術方面你顯得三層技衣設計你可以詳細講講你大概存了幾個月的數據它可問你數據量的大小數多少你數據的存儲上線是多少問你大概 Token值能存多少我倒是這個面臉的就不存在我問問問還有點就是多數拉格切塊不算是真正的Agent 因為很多拉格它其實就停留在了一個那種對話上面跟真正的Agent 不太一樣真正Agent 怎麼樣就是包裹上下文包裹機包裹工具掉用等等然後它的主體是一個Agent loop 就是一個循環它會每一次就用輸入一個問題之後我們請會通過一個外容不斷的循環它會判斷這一次它會接駁或是直接返回對話並退出如果音要做拉格應該要做 Agent 還有一個就是拉格我覺得做得人太多了一方面如果它做得非常好便是可能記住了它這個項目的亮點那大家是不是有可能拿去問下一個那邊是你我要在這方面做類似的創新項目你不要做到用話別人做到了就很容易就被別人逼下去或是因為太大眾了就沒有什麼新意容易讓人視覺疲勞就介紹一下我的新項目那 minibot 可能就簡單的描述一下這個項目怎麼做出來了主要參考了幾項項目是它開源的侵量級的智能體框架它大概就四千多行我覺得是一個非常有趣我們快速上手了解 AI 安全智能體甚至是速通成一個項目的很好的框架同時我有學了能 code 這個課程去開源的項目是它裡面的一些哈利斯設計想辦法把哈利斯設計融入這個 Nanable 它的黃架裡面同時我做這個項目是有參考一些小紅書上黃紅學 H 他的 P 可項目就介紹一下正和新內容先介紹記憶算項目管理我覺得這算是 Nanable 它的記憶就好這兩層記憶加工可能有些不準確大家繼續學想想想關於參考難道不懂他可能有些動態主動是把code 的他裡面的想想會有進行拆解太長的工具他就會換成一個站位符來要的方式還有記憶壓縮部分就這次先詳細詳細掌握這個互可其實算是一個實現的手段學現這些工具安全運行質地算是一個目的工具安全設計三層審批這個例子例如設計我工具全部的工具一線工具是白銘單可以用它直接放行所以讓它運行會名單的話可能有危險需要我這個用戶確認要不要運行會名單直接繼續不能運行這一個工具波子的意思就是比如這個 pre-tour use 就是在你調用工具之前它是一定會走的像是一個不發按鈕就你到土耳就一定會先觸發這個pre-tour use 在pre-tour use 裡面就可以用到我之前設計這個三層審批就在這裡判斷一下它是哪一個名單的然後它是審計的避完就是設計的 Benchmark任務級這部分說出來就是有參考到P-Code這個項目我介紹一下 Benchmark 大概是什麼情況 Benchmark就比如說你設計好一個這室的問題裡面你可以審一些比如任務的ID 任務任務裡面你輸入是什麼可以給上下文還可以放一些比如你的循環的預算值也可以放一些參考的判斷指標那到就是讓你的Agent 去執行這室的裡面讓它避行就讓它看它給出來的答案裡面比如說你查一個天氣流查背景的天氣大家是不是提到背景提到天氣這件事就是判斷你查這個天氣也不能循環太多次你查一個天氣你讓這個Agent 循環的十次可能超出那個循環預算就不算通過就通過這樣一個一個的設計任務級的方式可以得到也就是當前你的Agent 可以通過的百分別算是通過率你可以定型優化可以定型型和你的致力之後你說我這一次通過的任務級提高了多少 PT提高了多少這也是一個一款和評測的4位大概項目是講到這裡專業級的就大家參考一下就好大概還是後端的部分我主要寫 My Circle Radice 因為中經濟所以我個人找我的比較好之前學的是 Jama Jama 那些語言的八國被不太說我直接不寫上去想Log 就像我學Molog 就不寫白不寫也寫上去還有技術還有操作系統直接也可以放進去還有這個AICoding YepCoding 也比較重要的部分也算是口察的重點再介紹一下我來找實際心情式用了AI 幫助我做了哪些東西第一點就是先建立來幫我寫了但是大家需要有自己的判斷所以它寫得好不好然後比如我讓它找這個要求前面一個要點加帽加上後面加進描述的格式來寫我有時候它會輸出一些比較廢話的東西你可以讓它是剪解一點不是要求可以讓它就它有時候會小標題剩下小標題我就是說你給我放在統一行裡還有它寫得太難了寫得太高級了這方面你覺得要看你自己的水平能不能講出來如果沒有講不出來的話一定要讓它再開簡單一點我們還可以我們還可以接觸AI 來幫助你進行模擬面試再如果去BOSS上看一些崗位描述可以把那個崗位描述複製下來加上幫你檢例複製下來發給AI 跟他說我現在尋找LOMO實習半眼下面是關來把對我進行口打可以從項目八股算法按個方面就是 AI庫底方面我的項目其實就是 AI項目都是用 Y5庫底做的做這個用AI庫底是有一些好處的庫底的時候你可能就會用上一些有機會去比為壓死我一下開心會有好愛最愛的就趕重一下這個AI庫底大概是什麼個流程我也可以繼續 AI學習概念其實學習學習概念你也可以跟說裡面是關節當你某個問題問住你的話就可以到別人關就法外面是關然後法外面是關參考答案你開個市民然後說幫我記錄一下這一次問題你可以指定一個文件夾罪的他以後都往裡面記最後相關的練習還有這個 P-Core項目好的大家如果第一次分享就到這裡就說希望大家可以多點再多鬆鬆加上關注我

如何找到第一份agent实习项目分享整理版

Wed, 10 Jun 2026 00:00:00 GMT

如何找到第一份Agent实习 - 项目分享#

本文整理自一位计算机专业本科生的实习经验分享，主要涵盖个人背景、项目经历、面试准备及AI工具使用等方面。

个人背景#

学历：计算机相关专业本科生（中上水平）
技术栈：后端开发、全栈开发、Agent开发
求职目标：寻找Agent开发、后端开发或全栈开发方向的实习机会

实习时间线#

3月中旬：开始投递简历
3月23日：第一场面试（电话面），因准备不足未通过
5月中旬：使用优化后的AI项目重新开始面试
最终结果：获得多个Offer，包括某公司HR面（最终未通过）

项目经历#

1. 后端高并发项目#

项目来源：基于付费课程项目进行二次开发
技术栈：HMR（可能指某种高并发框架）+ 优化
项目特点：
- 支持高并发场景
- 进行了性能优化
- 适合作为面试项目展示

2. AI项目（MiniBot智能体）#

项目定位：从RAG项目转型而来的AI智能体项目
技术架构：基于开源智能体框架（约4000行代码）
核心功能：
- 智能对话与任务执行
- 工具调用与安全控制
- 记忆管理与压缩
- 基准测试评估

从RAG项目到MiniBot项目的转变#

转变原因分析：#

1. RAG项目的局限性#

应用场景限制：RAG更适合处理大规模数据（百万级以上），小型项目（如个人笔记）价值有限
技术时效性：RAG是2024年及之前较火的技术，AI领域技术迭代快，可能让面试官觉得缺乏对新技术的探索
实现复杂度：需要掌握向量数据库选择、分块策略、评测指标等多方面知识
同质化严重：做RAG项目的人太多，容易缺乏新意

2. MiniBot项目的优势#

真正Agent架构：包含上下文管理、工具调用、Agent循环等完整要素
技术新颖性：更符合当前AI Agent发展趋势
差异化竞争：相对较少人做类似的智能体项目

新项目（MiniBot）技术细节#

核心功能模块：#

1. 记忆管理系统#

两层记忆架构：短期记忆与长期记忆
记忆压缩：对过长内容进行压缩处理
动态记忆：根据上下文自动管理记忆内容

2. 工具安全设计#

三层审批机制：
- 白名单工具：直接放行
- 灰名单工具：需要用户确认
- 黑名单工具：禁止运行
Pre-tool Use钩子：工具调用前的安全检查点

3. 基准测试（Benchmark）系统#

任务级评估：设计具体问题场景进行测试
评估指标：
- 任务完成率
- 循环次数限制
- 结果准确性
持续优化：通过测试结果指导项目迭代

技术参考：#

开源智能体框架（约4000行代码）
《能Code》课程中的设计理念
小红书上的相关项目参考

AI辅助面试准备#

1. 简历优化#

格式规范：使用统一格式，前面加粗关键词，后面详细描述
数据量化：展示项目前后的性能指标变化
内容精简：避免废话，突出重点
难度控制：确保描述内容与自身水平匹配

2. 模拟面试#

岗位描述分析：从BOSS直聘等平台获取岗位JD
AI模拟面试：将简历和JD提供给AI进行模拟面试
多维度准备：
- 项目经验
- 八股文（基础知识）
- 算法题

3. 技术学习#

AI八股文：使用AI学习常见的AI面试问题
概念学习：遇到不懂的概念让AI解释
问题记录：建立问题集，方便复习回顾

4. 技术栈准备#

重点技术：MySQL、Redis（因为更符合当前求职市场需求）
补充技能：操作系统、AI Coding等
算法练习：使用AI辅助进行算法学习

总结#

找到第一份Agent实习的关键在于：

项目差异化：选择相对新颖且有深度的项目方向
技术深度：深入理解项目中的技术细节和设计思想
面试准备：系统性地准备项目介绍、八股文和算法
AI工具利用：善用AI辅助简历优化、模拟面试和技术学习
持续迭代：根据面试反馈不断优化项目和准备策略

整理说明：本文基于语音转录内容整理，修正了明显的口语化表达和错别字，优化了文档结构，使其更符合技术分享文档的规范。

如果一个GPU集群的LLM处理能力为1000tokens s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token s吗？怎么分析性能瓶颈整理

Wed, 10 Jun 2026 00:00:00 GMT

如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈#

问题#

如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？#

标准回答#

怎么分析性能瓶颈

如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈

如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈#

如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，那 1000 个用户分 10 批就处理完了。单用户实际体验到的速度是 10 tokens/s，不是 1 token/s。实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

扩展知识#

请求聚合与调度机制LLM 推理有个特点：一次 forward 只生成 1 个 token，然后循环生成下一个。1000 个用户同时来请求，GPU 不是一个一个处理，而是每轮同时算这 1000 个请求的下一个 token。这就需要一个请求聚合器来协调：1）把同时到达的请求按 token 长度打包，比如用户 A 发 2 个 token、用户 B 发 4 个、用户 C 发 6 个，聚合器会把短的补齐到相同长度，打成一个矩阵扔给 GPU 一次算完2）通常有个聚合窗口，比如每 5ms 或者攒够 32 个请求就发一批，跟公交车发车一个道理：不等人就浪费座位，等太久乘客就骂娘3）控制粒度是 token-level batching，同一时刻只处理所有请求的当前 token，算完再一起推进到下一个动态调度与优先级请求进来不会立刻推理，先进一个异步队列，调度器根据策略决定谁先算：1）优先级策略：付费用户优先、重试请求优先、token 少的先算完让出位置2）负载均衡：GPU 显存吃紧时减小 batch size，空闲时加大 batch 塞更多请求3）动态退场：已经生成完的请求退出 batch，新请求插进来，整个过程是一条流水线实际场景分析拿一个聊天机器人平台举例：1000 个用户并发，请求平均 20 tokens，GPU 最大 batch 128，吞吐 1000 tokens/s。调度可能是这样跑的：1）每 10ms 打一批，聚合 50~100 个请求2）所有请求每生成一个 token 就进入下一轮调度3）pipeline 里同时跑着多个 batch，每个 batch 装的是不同用户的不同 token最终每个用户实际体验到的响应速度是几十 token/s，远比简单除法算出来的 1 token/s 快。性能瓶颈分析思路遇到吞吐上不去或者延迟高，从这几个方向排查：1）显存瓶颈：KV Cache 占用太大，batch size 上不去，看 nvidia-smi 的显存占用2）计算瓶颈：GPU 利用率拉满但吞吐还是低，说明模型太大或者 batch 太小没喂饱 GPU3）调度瓶颈：队列堆积严重，调度器跟不上请求速度，看请求排队时间4）网络瓶颈：分布式推理场景下，节点间通信成瓶颈，看 NCCL 的耗时占比vLLM、TensorRT-LLM 这些推理框架都有 metrics 接口，可以直接看 batch size 分布、排队延迟、吞吐曲线，定位瓶颈点。Java 模拟示例用 Java 模拟并发请求和资源排队机制：▼java复制代码ExecutorServiceexecutor=Executors.newFixedThreadPool(100);SemaphoregpuTokens=newSemaphore(1000);// 模拟 1000 token/s 的能力for(inti=0; i <1000; i++) {

executor.submit(() -> {try{if(gpuTokens.tryAcquire(10,1, TimeUnit.SECONDS)) {

System.out.println(“Token allocated to user: ”+ Thread.currentThread().getName());

Thread.sleep(100);// 模拟推理延迟gpuTokens.release(10);

}else{

System.out.println(“Timeout, user dropped.”);

}

}catch(InterruptedException e) {

Thread.currentThread().interrupt();

}

});

}这段代码用 Semaphore 模拟 GPU 的 token 处理能力，每个用户请求 10 个 token，超时就丢弃。实际生产环境的调度比这复杂得多，但核心思想一样：资源有限，靠排队和批处理来提升整体吞吐。

面试官追问#

提问：vLLM 的 PagedAttention 机制是怎么优化显存利用率的？回答：传统做法是给每个请求预分配最大长度的 KV Cache，比如最大 2048 tokens 就分配 2048 的显存，但大多数请求用不完，显存浪费严重。PagedAttention 借鉴操作系统的分页思想，把 KV Cache 切成固定大小的 block，按需分配。请求来了先给一个 block，用完再分配下一个，就跟虚拟内存一样按需加载。这样显存利用率能从 20~30% 提升到 90% 以上，同样的显存能塞更多请求，吞吐直接翻几倍。- 提问：Continuous Batching 和传统的 Static Batching 有什么区别？
回答：Static Batching 是攒一批请求，等所有请求都生成完才处理下一批。问题是短请求早就生成完了还得等长请求，GPU 干等着浪费算力。Continuous Batching 是动态调度，短请求生成完就退出 batch，新请求马上插进来，整个过程像流水线一样不停转。vLLM、TensorRT-LLM 都用的这种方式，吞吐能比 Static Batching 高 2~3 倍。- 提问：推理服务的 First Token Latency 和 Time Per Output Token 怎么分别优化？
回答：First Token Latency 是首 token 延迟，主要卡在 prefill 阶段，整个 prompt 要一次性过一遍模型。优化方向是 prompt 压缩、KV Cache 预计算、prefill 和 decode 分离部署。Time Per Output Token 是后续每个 token 的生成耗时，主要看 decode 阶段的效率，优化方向是加大 batch size、用 speculative decoding 一次预测多个 token、量化降低计算量。两个指标侧重点不一样，First Token 影响用户体感的响应速度，TPOT 影响整体吞吐。- 提问：模型量化对推理性能有什么影响？INT8 和 FP16 怎么选？
回答：量化就是降低权重和激活值的精度，FP16 比 FP32 快一倍左右，INT8 比 FP16 又快一倍左右。但精度损失也是真实存在的，INT8 量化后模型效果可能会掉几个点。选型看场景：对精度要求高的用 FP16，追求极致吞吐且能接受一点效果损失的用 INT8。还有个折中方案是混合精度，attention 层用 FP16 保精度，FFN 层用 INT8 提速度。AWQ、GPTQ 这些量化方案在保精度上做了很多优化，实际效果损失比朴素 INT8 小很多。

请求聚合与调度机制动态调度与优先级实际场景分析性能瓶颈分析思路Java 模拟示例

提问：vLLM 的 PagedAttention 机制是怎么优化显存利用率的？提问：Continuous Batching 和传统的 Static Batching 有什么区别？提问：推理服务的 First Token Latency 和 Time Per Output Token 怎么分别优化？提问：模型量化对推理性能有什么影响？INT8 和 FP16 怎么选？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？用到了哪些特性？上次浏览：2026-03-16 15:12:36你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？如何实现程序和 AI 大模型的集成？有哪些方式？Agent 死循环问题有遇到过吗？如何解决？如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？11871. 如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，那 1000 个用户分 10 批就处理完了。单用户实际体验到的速度是 10 tokens/s，不是 1 token/s。实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

executor.submit(() -> {try{if(gpuTokens.tryAcquire(10,1, TimeUnit.SECONDS)) {

System.out.println(“Token allocated to user: ”+ Thread.currentThread().getName());

Thread.sleep(100);// 模拟推理延迟gpuTokens.release(10);

}else{

System.out.println(“Timeout, user dropped.”);

}

}catch(InterruptedException e) {

Thread.currentThread().interrupt();

}

});

提问：vLLM 的 PagedAttention 机制是怎么优化显存利用率的？回答：传统做法是给每个请求预分配最大长度的 KV Cache，比如最大 2048 tokens 就分配 2048 的显存，但大多数请求用不完，显存浪费严重。PagedAttention 借鉴操作系统的分页思想，把 KV Cache 切成固定大小的 block，按需分配。请求来了先给一个 block，用完再分配下一个，就跟虚拟内存一样按需加载。这样显存利用率能从 20~30% 提升到 90% 以上，同样的显存能塞更多请求，吞吐直接翻几倍。- 提问：Continuous Batching 和传统的 Static Batching 有什么区别？
回答：Static Batching 是攒一批请求，等所有请求都生成完才处理下一批。问题是短请求早就生成完了还得等长请求，GPU 干等着浪费算力。Continuous Batching 是动态调度，短请求生成完就退出 batch，新请求马上插进来，整个过程像流水线一样不停转。vLLM、TensorRT-LLM 都用的这种方式，吞吐能比 Static Batching 高 2~3 倍。- 提问：推理服务的 First Token Latency 和 Time Per Output Token 怎么分别优化？
回答：First Token Latency 是首 token 延迟，主要卡在 prefill 阶段，整个 prompt 要一次性过一遍模型。优化方向是 prompt 压缩、KV Cache 预计算、prefill 和 decode 分离部署。Time Per Output Token 是后续每个 token 的生成耗时，主要看 decode 阶段的效率，优化方向是加大 batch size、用 speculative decoding 一次预测多个 token、量化降低计算量。两个指标侧重点不一样，First Token 影响用户体感的响应速度，TPOT 影响整体吞吐。- 提问：模型量化对推理性能有什么影响？INT8 和 FP16 怎么选？
回答：量化就是降低权重和激活值的精度，FP16 比 FP32 快一倍左右，INT8 比 FP16 又快一倍左右。但精度损失也是真实存在的，INT8 量化后模型效果可能会掉几个点。选型看场景：对精度要求高的用 FP16，追求极致吞吐且能接受一点效果损失的用 INT8。还有个折中方案是混合精度，attention 层用 FP16 保精度，FFN 层用 INT8 提速度。AWQ、GPTQ 这些量化方案在保精度上做了很多优化，实际效果损失比朴素 INT8 小很多。

请求聚合与调度机制动态调度与优先级实际场景分析性能瓶颈分析思路Java 模拟示例

来源: 如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈.mhtml

关键点#

如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？#
怎么分析性能瓶颈如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？
怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。
LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。
GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，那 1000 个用户分 10 批就处理完了。单用户实际体验到的速度是 10 tokens/s，不是 1 token/s。实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

executor.submit(() -> {try{if(gpuTokens.tryAcquire(10,1, TimeUnit.SECONDS)) {

System.out.println(“Token allocated to user: ”+ Thread.currentThread().getName());

Thread.sleep(100);// 模拟推理延迟gpuTokens.release(10);

}else{

System.out.println(“Timeout, user dropped.”);

}

}catch(InterruptedException e) {

Thread.currentThread().interrupt();

}

});

提问：vLLM 的 PagedAttention 机制是怎么优化显存利用率的？回答：传统做法是给每个请求预分配最大长度的 KV Cache，比如最大 2048 tokens 就分配 2048 的显存，但大多数请求用不完，显存浪费严重。PagedAttention 借鉴操作系统的分页思想，把 KV Cache 切成固定大小的 block，按需分配。请求来了先给一个 block，用完再分配下一个，就跟虚拟内存一样按需加载。这样显存利用率能从 20~30% 提升到 90% 以上，同样的显存能塞更多请求，吞吐直接翻几倍。- 提问：Continuous Batching 和传统的 Static Batching 有什么区别？
回答：Static Batching 是攒一批请求，等所有请求都生成完才处理下一批。问题是短请求早就生成完了还得等长请求，GPU 干等着浪费算力。Continuous Batching 是动态调度，短请求生成完就退出 batch，新请求马上插进来，整个过程像流水线一样不停转。vLLM、TensorRT-LLM 都用的这种方式，吞吐能比 Static Batching 高 2~3 倍。- 提问：推理服务的 First Token Latency 和 Time Per Output Token 怎么分别优化？
回答：First Token Latency 是首 token 延迟，主要卡在 prefill 阶段，整个 prompt 要一次性过一遍模型。优化方向是 prompt 压缩、KV Cache 预计算、prefill 和 decode 分离部署。Time Per Output Token 是后续每个 token 的生成耗时，主要看 decode 阶段的效率，优化方向是加大 batch size、用 speculative decoding 一次预测多个 token、量化降低计算量。两个指标侧重点不一样，First Token 影响用户体感的响应速度，TPOT 影响整体吞吐。- 提问：模型量化对推理性能有什么影响？INT8 和 FP16 怎么选？
回答：量化就是降低权重和激活值的精度，FP16 比 FP32 快一倍左右，INT8 比 FP16 又快一倍左右。但精度损失也是真实存在的，INT8 量化后模型效果可能会掉几个点。选型看场景：对精度要求高的用 FP16，追求极致吞吐且能接受一点效果损失的用 INT8。还有个折中方案是混合精度，attention 层用 FP16 保精度，FFN 层用 INT8 提速度。AWQ、GPTQ 这些量化方案在保精度上做了很多优化，实际效果损失比朴素 INT8 小很多。

请求聚合与调度机制动态调度与优先级实际场景分析性能瓶颈分析思路Java 模拟示例

你在 AI 超级智能体项目中如何利用 Spring AI 开发应用？用到了哪些特性？上次浏览：2026-03-16 15:12:36你有多个知识库，做 RAG 的时候，怎么保证查询效率和准确性兼容，并尽可能减少幻觉？如何实现程序和 AI 大模型的集成？有哪些方式？Agent 死循环问题有遇到过吗？如何解决？如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？11871. 如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，那 1000 个用户分 10 批就处理完了。单用户实际体验到的速度是 10 tokens/s，不是 1 token/s。实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

executor.submit(() -> {try{if(gpuTokens.tryAcquire(10,1, TimeUnit.SECONDS)) {

System.out.println(“Token allocated to user: ”+ Thread.currentThread().getName());

Thread.sleep(100);// 模拟推理延迟gpuTokens.release(10);

}else{

System.out.println(“Timeout, user dropped.”);

}

}catch(InterruptedException e) {

Thread.currentThread().interrupt();

}

});

提问：vLLM 的 PagedAttention 机制是怎么优化显存利用率的？回答：传统做法是给每个请求预分配最大长度的 KV Cache，比如最大 2048 tokens 就分配 2048 的显存，但大多数请求用不完，显存浪费严重。PagedAttention 借鉴操作系统的分页思想，把 KV Cache 切成固定大小的 block，按需分配。请求来了先给一个 block，用完再分配下一个，就跟虚拟内存一样按需加载。这样显存利用率能从 20~30% 提升到 90% 以上，同样的显存能塞更多请求，吞吐直接翻几倍。- 提问：Continuous Batching 和传统的 Static Batching 有什么区别？
回答：Static Batching 是攒一批请求，等所有请求都生成完才处理下一批。问题是短请求早就生成完了还得等长请求，GPU 干等着浪费算力。Continuous Batching 是动态调度，短请求生成完就退出 batch，新请求马上插进来，整个过程像流水线一样不停转。vLLM、TensorRT-LLM 都用的这种方式，吞吐能比 Static Batching 高 2~3 倍。- 提问：推理服务的 First Token Latency 和 Time Per Output Token 怎么分别优化？
回答：First Token Latency 是首 token 延迟，主要卡在 prefill 阶段，整个 prompt 要一次性过一遍模型。优化方向是 prompt 压缩、KV Cache 预计算、prefill 和 decode 分离部署。Time Per Output Token 是后续每个 token 的生成耗时，主要看 decode 阶段的效率，优化方向是加大 batch size、用 speculative decoding 一次预测多个 token、量化降低计算量。两个指标侧重点不一样，First Token 影响用户体感的响应速度，TPOT 影响整体吞吐。- 提问：模型量化对推理性能有什么影响？INT8 和 FP16 怎么选？
回答：量化就是降低权重和激活值的精度，FP16 比 FP32 快一倍左右，INT8 比 FP16 又快一倍左右。但精度损失也是真实存在的，INT8 量化后模型效果可能会掉几个点。选型看场景：对精度要求高的用 FP16，追求极致吞吐且能接受一点效果损失的用 INT8。还有个折中方案是混合精度，attention 层用 FP16 保精度，FFN 层用 INT8 提速度。AWQ、GPTQ 这些量化方案在保精度上做了很多优化，实际效果损失比朴素 INT8 小很多。

请求聚合与调度机制动态调度与优先级实际场景分析性能瓶颈分析思路Java 模拟示例

来源: 如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈.mhtml

如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？#
- 怎么分析性能瓶颈如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？
- 怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。
- LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。
- GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。
本文已做格式统一与噪声清理，保留原始语义。
如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈#
如果一个GPU集群的LLM处理能力为1000tokens_s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token_s吗？怎么分析性能瓶颈
如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈#
1. 如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈VIP中等后端场景题大模型标记分享131248面试问答不会简单平均成每人 1 token/s，实际上每个用户看到的响应速度可能是几十 token/s。LLM 推理不是把算力切成 1000 份分给 1000 个用户，而是靠批处理把多个请求打包到一起算。GPU 擅长的就是并行计算，100 个请求打成一个 batch，计算耗时跟处理单个请求差不多，吞吐量直接翻几十倍。假设每次批处理包含 100 个用户的请求，每个用户请求 10 tokens，那 1000 个用户分 10 批就处理完了。单用户实际体验到的速度是 10 tokens/s，不是 1 token/s。实际响应速度取决于三个核心因素：请求的 token 长度、batch 大小策略、排队调度机制。

executor.submit(() -> {try{if(gpuTokens.tryAcquire(10,1, TimeUnit.SECONDS)) {
本文已做格式统一与噪声清理，保留原始语义。

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？整理

Wed, 10 Jun 2026 00:00:00 GMT

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？#

问题#

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？

标准回答#

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1179面试问答裁剪是把早期消息直接丢掉，简单粗暴但会丢信息。Compaction（压实/压缩）换了个思路：用 LLM 把一大段对话历史”压缩”成一段精炼摘要，然后用摘要替换掉原始消息。打个比方，就像把一本 300 页的会议记录压缩成 5 页的纪要。篇幅大幅缩减，但关键决议、待办事项、重要结论都保留了。这样 Context 窗口腾出来了，关键信息也没丢。OpenClaw 的 Compaction 核心流程分 4 步走：分块（Chunking）：先把待压缩的消息按 token 预算切成多个 chunk（默认切 2 段）。切分在单条消息的边界进行，chunk 大小由 Context 窗口比例自适应计算。同时把最近几轮对话（默认 3 轮）分离出来保留原文，只压缩更早的消息。逐块摘要（Per-chunk Summarization）：每个 chunk 分别发给 LLM 生成一段摘要。如果某条消息超大（超过 Context 窗口的 50%），会走降级路径：先跳过超大消息只压缩小消息，再标注超大消息被省略了。合并摘要（Merge Summaries）：把多段局部摘要再调一次 LLM 融合成一份连贯的最终摘要，要求保留：进行中的任务状态、批量操作进度、用户最后的请求、决策及原因、待办事项和约束条件。摘要增强（Summary Augmentation）：在合并摘要基础上，追加额外上下文，比如工具调用失败记录（包含 exit code 和 error 状态）、文件操作记录（读过和修改过的文件列表）、最近几轮对话的原文摘要、以及从 AGENTS.md 提取的关键规则。最终结果替换掉原始消息，写入 session 历史。这个设计的核心理念是：宁可多花点 token 调一次 LLM 做摘要，也不要丢掉关键信息让后续任务翻车。

扩展知识#

摘要质量检查压缩不是调一次 LLM 就完事了，OpenClaw 做了专门的质量校验。压缩完成后会检查摘要是否包含 5 个必要的结构化章节：Decisions（做过的决策）Open TODOs（未完成的任务）Constraints/Rules（约束条件）Pending user asks（用户尚未被回应的请求）Exact identifiers（需要精确保留的标识符）除了章节完整性之外，质量审计还会检查两个方面：摘要是否保留了从最近消息中提取的关键标识符（strict 策略下）以及摘要内容是否反映了用户最新的请求。不过需要注意，这套质量检查+重试机制（quality guard）默认是关闭的，需要在配置中显式启用。启用后，如果摘要未通过质量审计，会触发重试（最多重试 1 次，可配置，上限 3 次）。即使不启用 quality guard，结构化章节的要求也会通过 prompt 指令传达给 LLM，只是不会做事后校验和自动重试。标识符保留策略摘要有一个特别容易踩的坑：LLM 会把 UUID、hash、API key、URL、文件名这些标识符”概括”掉。比如把file: src/controllers/UserController.ts概括成”修改了一个控制器文件”，后续 Agent 想继续操作这个文件就找不到了。OpenClaw 默认采用strict 策略，要求摘要中精确保留所有不可重构的标识符。Compaction 的 prompt 里会给 LLM 一条通用指令，明确要求原样保留 UUID、hash、ID、token、API key、主机名、IP、端口、URL、文件名等。同时要求摘要必须包含一个 Exact identifiers 章节来列出关键标识符。注意 prompt 不会列举本次对话中出现的具体标识符，具体标识符的检验是在质量审计阶段，从最近 10 条消息中自动提取并比对摘要内容。Memory Flush 联动OpenClaw 还有一个很巧妙的设计：在接近 Compaction 阈值的时候，会先触发一次额外的 Agent 轮次（Memory Flush），让模型把重要信息主动写入 memory 目录。你可以把它理解成”考试交卷前最后再检查一遍”。模型知道自己的对话历史马上要被压缩了，所以赶紧把最重要的信息往长期存储里写一份。这样即使 Compaction 的摘要质量不理想，关键信息在 memory 目录里还有一份备份。这是短期记忆到长期记忆的逃生通道，保证信息不会因为压缩而彻底丢失。Post-compaction Context 注入压缩完成后，系统会从 AGENTS.md 里读取 “Session Startup” 和 “Red Lines” 两个部分，重新注入到上下文里。为什么要这么做？因为 Compaction 把早期消息替换成了摘要，但 Agent 的启动流程和红线规则可能就在那些被替换掉的早期消息里。如果不重新注入，模型压缩完之后可能忘了自己有哪些不能碰的红线，行为就可能失控。工具调用失败的特殊处理Compaction 还会专门提取并保留工具调用失败的信息，包括 exit code 和 error 状态。这些失败信息对后续任务成功率至关重要。比如 Agent 之前尝试过写入某个文件被权限拒绝了，如果这条失败记录在压缩时被丢掉，Agent 压缩后又会傻傻地去试一次，再失败，白白浪费一轮循环。保留失败记录就能让 Agent 直接跳过已知不可行的路径，换别的方案。

面试官追问#

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？回答：单次 Compaction 大概消耗几千 token，跟一轮正常对话差不多。但它能把几万 token 的对话历史压缩到几千 token 的摘要，后续每一轮对话都省了大量 Context 开销。从整个 session 生命周期看，做 Compaction 的 token 总消耗远低于不做 Compaction 把完整历史一直带着。越长的对话收益越明显，100 轮的对话如果不压缩，光 Context 填充就要烧掉几十万 token 甚至更多。- 提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？
回答：chunk 大小按 token 上限来切，默认是模型 Context 窗口的 40%（基准比例），会根据消息平均大小自适应调整（最低 15%），同时预留约 4096 token 给摘要 prompt 和推理预算。切的时候是在单条消息的边界切，不会把一条消息拆到两个 chunk 里，但不会刻意保证 user+assistant 对话回合的完整性。chunk 之间确实可能丢跨 chunk 的上下文关联，所以才需要合并摘要阶段，让 LLM 把多段摘要融合起来，补上跨段的逻辑关系。另外还有 20% 的安全缓冲来补偿 token 估算不准的问题。- 提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？
回答：按 token 数触发。每次拼完整的 prompt 之前会算一下当前对话历史占了多少 token，超过阈值就触发 Compaction。用固定轮次不靠谱，因为每轮对话的长度差异很大，有的轮次用户就说了一句话，有的轮次 Agent 调了 5 个工具返回一大堆结果。按 token 数控制才能精确地管住 Context 窗口的使用率。- 提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？
回答：会。这是 strict 策略的一个已知代价，摘要会比宽松策略长一些。但在实际场景中，标识符占的 token 比例并不大，通常几十个 token 就能覆盖一个 session 里的所有关键标识符。相比丢失标识符导致后续任务失败再重试的 token 浪费，保留它们的成本低得多。如果确实需要清理过时标识符，可以在 Memory Flush 阶段让 Agent 主动判断哪些标识符还有用，只把有用的写入长期记忆。作者：Yes面试鸭官方 Compaction 压缩：用 LLM 把一大段对话历史压缩成一段精炼摘要，然后用摘要替换掉原始消息

OpenClaw 的 Compaction 核心流程分 4 步走：分块 Chunking ：先把待压缩的消息按 token 预算切成多个 ch展开新页面打开2026-03-17 21:4900回复晚夜微雨问海棠特训营一、对话历史超长、裁剪失效时的终极解决方案当渐进式裁剪（Pruning）仍无法控制Token占用时，行业通用的终极方案包括：对话压缩（Compaction）：用LLM将旧对话历史总结为紧凑摘要，替换原始内容，是最直接有效的手段。分层记忆+RAG召回：将旧历史归档展开新页面打开2026-03-15 09:2200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

摘要质量检查标识符保留策略Memory Flush 联动Post-compaction Context 注入工具调用失败的特殊处理

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:28在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？如果一个 Agent 系统要同时接入 Telegram、飞书、钉钉等渠道，你会怎么设计抽象层？OpenClaw 的 Channel Plugin 接口是怎么设计的？13231. 当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1179面试问答裁剪是把早期消息直接丢掉，简单粗暴但会丢信息。Compaction（压实/压缩）换了个思路：用 LLM 把一大段对话历史”压缩”成一段精炼摘要，然后用摘要替换掉原始消息。打个比方，就像把一本 300 页的会议记录压缩成 5 页的纪要。篇幅大幅缩减，但关键决议、待办事项、重要结论都保留了。这样 Context 窗口腾出来了，关键信息也没丢。OpenClaw 的 Compaction 核心流程分 4 步走：分块（Chunking）：先把待压缩的消息按 token 预算切成多个 chunk（默认切 2 段）。切分在单条消息的边界进行，chunk 大小由 Context 窗口比例自适应计算。同时把最近几轮对话（默认 3 轮）分离出来保留原文，只压缩更早的消息。逐块摘要（Per-chunk Summarization）：每个 chunk 分别发给 LLM 生成一段摘要。如果某条消息超大（超过 Context 窗口的 50%），会走降级路径：先跳过超大消息只压缩小消息，再标注超大消息被省略了。合并摘要（Merge Summaries）：把多段局部摘要再调一次 LLM 融合成一份连贯的最终摘要，要求保留：进行中的任务状态、批量操作进度、用户最后的请求、决策及原因、待办事项和约束条件。摘要增强（Summary Augmentation）：在合并摘要基础上，追加额外上下文，比如工具调用失败记录（包含 exit code 和 error 状态）、文件操作记录（读过和修改过的文件列表）、最近几轮对话的原文摘要、以及从 AGENTS.md 提取的关键规则。最终结果替换掉原始消息，写入 session 历史。这个设计的核心理念是：宁可多花点 token 调一次 LLM 做摘要，也不要丢掉关键信息让后续任务翻车。

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？回答：单次 Compaction 大概消耗几千 token，跟一轮正常对话差不多。但它能把几万 token 的对话历史压缩到几千 token 的摘要，后续每一轮对话都省了大量 Context 开销。从整个 session 生命周期看，做 Compaction 的 token 总消耗远低于不做 Compaction 把完整历史一直带着。越长的对话收益越明显，100 轮的对话如果不压缩，光 Context 填充就要烧掉几十万 token 甚至更多。- 提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？
回答：chunk 大小按 token 上限来切，默认是模型 Context 窗口的 40%（基准比例），会根据消息平均大小自适应调整（最低 15%），同时预留约 4096 token 给摘要 prompt 和推理预算。切的时候是在单条消息的边界切，不会把一条消息拆到两个 chunk 里，但不会刻意保证 user+assistant 对话回合的完整性。chunk 之间确实可能丢跨 chunk 的上下文关联，所以才需要合并摘要阶段，让 LLM 把多段摘要融合起来，补上跨段的逻辑关系。另外还有 20% 的安全缓冲来补偿 token 估算不准的问题。- 提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？
回答：按 token 数触发。每次拼完整的 prompt 之前会算一下当前对话历史占了多少 token，超过阈值就触发 Compaction。用固定轮次不靠谱，因为每轮对话的长度差异很大，有的轮次用户就说了一句话，有的轮次 Agent 调了 5 个工具返回一大堆结果。按 token 数控制才能精确地管住 Context 窗口的使用率。- 提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？
回答：会。这是 strict 策略的一个已知代价，摘要会比宽松策略长一些。但在实际场景中，标识符占的 token 比例并不大，通常几十个 token 就能覆盖一个 session 里的所有关键标识符。相比丢失标识符导致后续任务失败再重试的 token 浪费，保留它们的成本低得多。如果确实需要清理过时标识符，可以在 Memory Flush 阶段让 Agent 主动判断哪些标识符还有用，只把有用的写入长期记忆。作者：Yes面试鸭官方 Compaction 压缩：用 LLM 把一大段对话历史压缩成一段精炼摘要，然后用摘要替换掉原始消息

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

摘要质量检查标识符保留策略Memory Flush 联动Post-compaction Context 注入工具调用失败的特殊处理

来源: 当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？.mhtml

关键点#

当对话历史实在太长、裁剪也不够用时，还有什么办法？#
什么是 Compaction？
OpenClaw 的 Compaction 策略是怎样的？
问题#

当对话历史实在太长、裁剪也不够用时，还有什么办法？

什么是 Compaction？

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？

标准回答#
问题#

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？回答：单次 Compaction 大概消耗几千 token，跟一轮正常对话差不多。但它能把几万 token 的对话历史压缩到几千 token 的摘要，后续每一轮对话都省了大量 Context 开销。从整个 session 生命周期看，做 Compaction 的 token 总消耗远低于不做 Compaction 把完整历史一直带着。越长的对话收益越明显，100 轮的对话如果不压缩，光 Context 填充就要烧掉几十万 token 甚至更多。- 提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？
回答：chunk 大小按 token 上限来切，默认是模型 Context 窗口的 40%（基准比例），会根据消息平均大小自适应调整（最低 15%），同时预留约 4096 token 给摘要 prompt 和推理预算。切的时候是在单条消息的边界切，不会把一条消息拆到两个 chunk 里，但不会刻意保证 user+assistant 对话回合的完整性。chunk 之间确实可能丢跨 chunk 的上下文关联，所以才需要合并摘要阶段，让 LLM 把多段摘要融合起来，补上跨段的逻辑关系。另外还有 20% 的安全缓冲来补偿 token 估算不准的问题。- 提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？
回答：按 token 数触发。每次拼完整的 prompt 之前会算一下当前对话历史占了多少 token，超过阈值就触发 Compaction。用固定轮次不靠谱，因为每轮对话的长度差异很大，有的轮次用户就说了一句话，有的轮次 Agent 调了 5 个工具返回一大堆结果。按 token 数控制才能精确地管住 Context 窗口的使用率。- 提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？
回答：会。这是 strict 策略的一个已知代价，摘要会比宽松策略长一些。但在实际场景中，标识符占的 token 比例并不大，通常几十个 token 就能覆盖一个 session 里的所有关键标识符。相比丢失标识符导致后续任务失败再重试的 token 浪费，保留它们的成本低得多。如果确实需要清理过时标识符，可以在 Memory Flush 阶段让 Agent 主动判断哪些标识符还有用，只把有用的写入长期记忆。作者：Yes面试鸭官方 Compaction 压缩：用 LLM 把一大段对话历史压缩成一段精炼摘要，然后用摘要替换掉原始消息

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

摘要质量检查标识符保留策略Memory Flush 联动Post-compaction Context 注入工具调用失败的特殊处理

解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:28在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？Agent 调用工具可能返回超大结果（比如代码搜索返回 50KB），这会带来什么问题？你会怎么处理？OpenClaw 是怎么做的？当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？如果一个 Agent 系统要同时接入 Telegram、飞书、钉钉等渠道，你会怎么设计抽象层？OpenClaw 的 Channel Plugin 接口是怎么设计的？13231. 当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1179面试问答裁剪是把早期消息直接丢掉，简单粗暴但会丢信息。Compaction（压实/压缩）换了个思路：用 LLM 把一大段对话历史”压缩”成一段精炼摘要，然后用摘要替换掉原始消息。打个比方，就像把一本 300 页的会议记录压缩成 5 页的纪要。篇幅大幅缩减，但关键决议、待办事项、重要结论都保留了。这样 Context 窗口腾出来了，关键信息也没丢。OpenClaw 的 Compaction 核心流程分 4 步走：分块（Chunking）：先把待压缩的消息按 token 预算切成多个 chunk（默认切 2 段）。切分在单条消息的边界进行，chunk 大小由 Context 窗口比例自适应计算。同时把最近几轮对话（默认 3 轮）分离出来保留原文，只压缩更早的消息。逐块摘要（Per-chunk Summarization）：每个 chunk 分别发给 LLM 生成一段摘要。如果某条消息超大（超过 Context 窗口的 50%），会走降级路径：先跳过超大消息只压缩小消息，再标注超大消息被省略了。合并摘要（Merge Summaries）：把多段局部摘要再调一次 LLM 融合成一份连贯的最终摘要，要求保留：进行中的任务状态、批量操作进度、用户最后的请求、决策及原因、待办事项和约束条件。摘要增强（Summary Augmentation）：在合并摘要基础上，追加额外上下文，比如工具调用失败记录（包含 exit code 和 error 状态）、文件操作记录（读过和修改过的文件列表）、最近几轮对话的原文摘要、以及从 AGENTS.md 提取的关键规则。最终结果替换掉原始消息，写入 session 历史。这个设计的核心理念是：宁可多花点 token 调一次 LLM 做摘要，也不要丢掉关键信息让后续任务翻车。

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？回答：单次 Compaction 大概消耗几千 token，跟一轮正常对话差不多。但它能把几万 token 的对话历史压缩到几千 token 的摘要，后续每一轮对话都省了大量 Context 开销。从整个 session 生命周期看，做 Compaction 的 token 总消耗远低于不做 Compaction 把完整历史一直带着。越长的对话收益越明显，100 轮的对话如果不压缩，光 Context 填充就要烧掉几十万 token 甚至更多。- 提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？
回答：chunk 大小按 token 上限来切，默认是模型 Context 窗口的 40%（基准比例），会根据消息平均大小自适应调整（最低 15%），同时预留约 4096 token 给摘要 prompt 和推理预算。切的时候是在单条消息的边界切，不会把一条消息拆到两个 chunk 里，但不会刻意保证 user+assistant 对话回合的完整性。chunk 之间确实可能丢跨 chunk 的上下文关联，所以才需要合并摘要阶段，让 LLM 把多段摘要融合起来，补上跨段的逻辑关系。另外还有 20% 的安全缓冲来补偿 token 估算不准的问题。- 提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？
回答：按 token 数触发。每次拼完整的 prompt 之前会算一下当前对话历史占了多少 token，超过阈值就触发 Compaction。用固定轮次不靠谱，因为每轮对话的长度差异很大，有的轮次用户就说了一句话，有的轮次 Agent 调了 5 个工具返回一大堆结果。按 token 数控制才能精确地管住 Context 窗口的使用率。- 提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？
回答：会。这是 strict 策略的一个已知代价，摘要会比宽松策略长一些。但在实际场景中，标识符占的 token 比例并不大，通常几十个 token 就能覆盖一个 session 里的所有关键标识符。相比丢失标识符导致后续任务失败再重试的 token 浪费，保留它们的成本低得多。如果确实需要清理过时标识符，可以在 Memory Flush 阶段让 Agent 主动判断哪些标识符还有用，只把有用的写入长期记忆。作者：Yes面试鸭官方 Compaction 压缩：用 LLM 把一大段对话历史压缩成一段精炼摘要，然后用摘要替换掉原始消息

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

摘要质量检查标识符保留策略Memory Flush 联动Post-compaction Context 注入工具调用失败的特殊处理

来源: 当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？.mhtml

当对话历史实在太长、裁剪也不够用时，还有什么办法？#
- 什么是 Compaction？
- OpenClaw 的 Compaction 策略是怎样的？
本文已做格式统一与噪声清理，保留原始语义。
当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？
当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？#
1. 当对话历史实在太长、裁剪也不够用时，还有什么办法？什么是 Compaction？OpenClaw 的 Compaction 策略是怎样的？NEW中等AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享1179面试问答裁剪是把早期消息直接丢掉，简单粗暴但会丢信息。Compaction（压实/压缩）换了个思路：用 LLM 把一大段对话历史”压缩”成一段精炼摘要，然后用摘要替换掉原始消息。打个比方，就像把一本 300 页的会议记录压缩成 5 页的纪要。篇幅大幅缩减，但关键决议、待办事项、重要结论都保留了。这样 Context 窗口腾出来了，关键信息也没丢。OpenClaw 的 Compaction 核心流程分 4 步走：分块（Chunking）：先把待压缩的消息按 token 预算切成多个 chunk（默认切 2 段）。切分在单条消息的边界进行，chunk 大小由 Context 窗口比例自适应计算。同时把最近几轮对话（默认 3 轮）分离出来保留原文，只压缩更早的消息。逐块摘要（Per-chunk Summarization）：每个 chunk 分别发给 LLM 生成一段摘要。如果某条消息超大（超过 Context 窗口的 50%），会走降级路径：先跳过超大消息只压缩小消息，再标注超大消息被省略了。合并摘要（Merge Summaries）：把多段局部摘要再调一次 LLM 融合成一份连贯的最终摘要，要求保留：进行中的任务状态、批量操作进度、用户最后的请求、决策及原因、待办事项和约束条件。摘要增强（Summary Augmentation）：在合并摘要基础上，追加额外上下文，比如工具调用失败记录（包含 exit code 和 error 状态）、文件操作记录（读过和修改过的文件列表）、最近几轮对话的原文摘要、以及从 AGENTS.md 提取的关键规则。最终结果替换掉原始消息，写入 session 历史。这个设计的核心理念是：宁可多花点 token 调一次 LLM 做摘要，也不要丢掉关键信息让后续任务翻车。

提问：Compaction 本身也要调 LLM，那 token 开销大不大？会不会得不偿失？回答：单次 Compaction 大概消耗几千 token，跟一轮正常对话差不多。但它能把几万 token 的对话历史压缩到几千 token 的摘要，后续每一轮对话都省了大量 Context 开销。从整个 session 生命周期看，做 Compaction 的 token 总消耗远低于不做 Compaction 把完整历史一直带着。越长的对话收益越明显，100 轮的对话如果不压缩，光 Context 填充就要烧掉几十万 token 甚至更多。- 提问：分段摘要的 chunk 大小怎么定的？切太小会不会丢上下文？
回答：chunk 大小按 token 上限来切，默认是模型 Context 窗口的 40%（基准比例），会根据消息平均大小自适应调整（最低 15%），同时预留约 4096 token 给摘要 prompt 和推理预算。切的时候是在单条消息的边界切，不会把一条消息拆到两个 chunk 里，但不会刻意保证 user+assistant 对话回合的完整性。chunk 之间确实可能丢跨 chunk 的上下文关联，所以才需要合并摘要阶段，让 LLM 把多段摘要融合起来，补上跨段的逻辑关系。另外还有 20% 的安全缓冲来补偿 token 估算不准的问题。- 提问：Compaction 触发的时机是什么？是固定轮次触发还是按 token 数触发？
回答：按 token 数触发。每次拼完整的 prompt 之前会算一下当前对话历史占了多少 token，超过阈值就触发 Compaction。用固定轮次不靠谱，因为每轮对话的长度差异很大，有的轮次用户就说了一句话，有的轮次 Agent 调了 5 个工具返回一大堆结果。按 token 数控制才能精确地管住 Context 窗口的使用率。- 提问：strict 策略保留标识符，但有些标识符已经过时了不需要了，不会造成摘要膨胀吗？
回答：会。这是 strict 策略的一个已知代价，摘要会比宽松策略长一些。但在实际场景中，标识符占的 token 比例并不大，通常几十个 token 就能覆盖一个 session 里的所有关键标识符。相比丢失标识符导致后续任务失败再重试的 token 浪费，保留它们的成本低得多。如果确实需要清理过时标识符，可以在 Memory Flush 阶段让 Agent 主动判断哪些标识符还有用，只把有用的写入长期记忆。作者：Yes面试鸭官方- Compaction 压缩：用 LLM 把一大段对话历史压缩成一段精炼摘要，然后用摘要替换掉原始消息
OpenClaw 的 Compaction 核心流程分 4 步走：分块 Chunking ：先把待压缩的消息按 token 预算切成多个 ch展开新页面打开2026-03-17 21:4900回复晚夜微雨问海棠特训营一、对话历史超长、裁剪失效时的终极解决方案当渐进式裁剪（Pruning）仍无法控制Token占用时，行业通用的终极方案包括：对话压缩（Compaction）：用LLM将旧对话历史总结为紧凑摘要，替换原始内容，是最直接有效的手段。分层记忆+RAG召回：将旧历史归档展开新页面打开2026-03-15 09:2200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

摘要质量检查标识符保留策略Memory Flush 联动Post-compaction Context 注入工具调用失败的特殊处理

本文已做格式统一与噪声清理，保留原始语义。

校招生写Agent项目最怕这5个追问

Wed, 10 Jun 2026 00:00:00 GMT

校招生写Agent项目，最怕这5个追问#

来源：小红书 @黄同学h 原文链接：http://xhslink.com/o/5TeS1z9FWsQ 发布时间：2026-04-11 标签：Agent、Agent开发、后端开发、互联网大厂、Agent项目收藏 311 · 点赞 222 · 评论 4

很多同学现在都会在简历上补一个 Agent 项目，但真正拉开差距的，是面试官顺着往下问的时候，你能不能讲明白。

我自己前实习和秋招那段时间，很多项目和经历其实都是按这个思路去设计的。一个好的项目，不是功能点多，而是能让人有好奇心继续问下去。只要对方愿意继续问，你就有机会把后面的场景、方案、收益讲完整。

这篇文章我想聊的是：如果你简历上写了 Agent 项目，面试官最容易会从哪些地方继续追问；以及为什么很多项目做出来了，最后还是会在追问里讲散。你会发现，后面的追问其实不是黑盒，基本都会落到几个固定方向。

如果你现在也在准备 Agent 项目、想写简历、或者想把项目讲得更像一个能扛面试的工程项目，这篇应该会对你有帮助。

好的项目，不是功能点多，而是能让人继续问下去。

我自己前实习和秋招那段时间，很多项目和经历其实都是按这个思路去设计的。我能在短短的一分钟介绍之后，就让面试官有提问的欲望，从而拿捏项目拷打环节。

如果项目只是功能罗列，那面试官最多听你讲一轮，很难继续往下问。但如果你的项目里有明确的场景、有设计取舍、有合适的方案、有指标收益，后面的追问其实不是黑盒，基本都会落到几个很固定的方向。

所以做 Agent 项目的时候，不是做完以后再想面试官会怎么问我，而是一开始就要想清楚：如果这个项目真的让人想继续问下去，最容易会问到哪里？

我自己前实习和秋招那段时间，反复被问、反复复盘下来，Agent 项目最常见的，基本就是下面这5个方向。

追问1：你这个项目，到底在解决什么问题？#

很多人介绍项目时，上来就是报菜名式地：

接了 tool calling
做了 memory
支持多轮对话
接了 shell / MCP / browser

但你把这些东西列完，面试官其实还是会继续问：

所以你为什么要做这个项目？它到底想解决什么问题？

如果这个点答不清楚，项目就难以有差异度，很容易让面试官感觉：今天这场面试又要听一个 toy project 了。

我觉得一个优秀的思路是，从你自己的痛点出发，带点产品 sense。比如我做的 pico 这个项目，我就会说：

我之所以要自己做个 coding agent，有两点：

1. 可控性。 平时我也会用 Claude Code 这类产品，但很多关键东西对用户来说其实是黑盒，比如 prompt 是怎么拼的、上下文是怎么组装的、工具在什么条件下会被调用，我很难真正判断它为什么这次做对了、下次又为什么会跑偏，某种程度上有点像抽卡。

2. 隐私和部署要求。 实验室有些项目本身有保密约束，不适合直接放到外部开源服务里做，所以我也希望这套 agent 从工具到模型都能自己控制。我在项目里预留了接开源模型的能力，比如可以直接接实验室已经部署好的 Qwen，这样在需要保密的场景下也能真正用起来。

如果有这样的描述，结合自己的痛点，把为什么 + 解决什么问题表达清楚，那面试官对你这个项目的好奇心会多很多。你们会很有话题聊。

追问2：为什么这里要做成 Agent？为什么不直接用现成方案？#

你刚解释完为什么这里要做成 Agent，对方很快就会接着问：

那为什么不是普通 Workflow？为什么不是直接用现成方案？

这类问题一旦被问到，面试官其实就在判断两件事：

你有没有想清楚”为什么这里需要 Agent”
你是不是只是在重复造轮子

因为现在现成方案已经很多了。

你做 code agent，逃不开 Claude Code、OpenCode。你做更通用的 Agent，也很容易被问到 OpenClaw、Hermes 这类系统。

所以你得讲清楚：

为什么这里需要模型做动态决策
为什么不是固定流程
为什么不是直接拿成熟方案来拼
你自己做的价值到底在哪

如果你只能回答一句”我想练练手”，这个项目在面试里基本撑不住。

追问3：系统为什么不会失控？#

很多 Agent 项目一开始看起来都挺顺：能对话，能调工具，能跑几轮，甚至还能给面试官演示一下。真正往下问的时候，问题就来了：

工具为什么不会乱调
状态为什么不会出现偏移
上下文为什么不会越堆越乱
memory 为什么不会把旧信息一直带着跑
长任务中间崩了怎么办

很多项目到这里就接不住了。因为大家在做项目的时候最多达到”这个东西跑通过”的程度。但真到面试里，大家更容易挂掉的地方不是它跑没跑通，而是顺着往下问时，你讲不清它为什么没有一路跑偏，为什么还能稳定地跑下去。

追问4：上下文和 memory，到底怎么管？#

上下文和 memory 是每一个 agent 都逃不开的话题，属于是必考的项目问题。

你一上来就说自己做了 memory、做了上下文压缩、做了长期记忆。但面试官真正想了解的是：

你到底让它记住了什么
什么该进 prompt，什么不该进
为什么不是把历史全塞进去
旧结论过期了怎么办
你的方案是怎么做的，有考虑你的 agent 具体场景吗

面试官不是在听你会不会背术语。他是在看你有没有真正想过：Agent 什么时候该记，什么时候该忘。

追问5：你了解这个方向上已经有什么成熟方案吗？你自己的项目跟它们差在哪？#

不少同学做项目的时候，注意力都放在我把这个东西做出来了。但面试官继续往下问的时候，往往还会在意另一件事：

你做这个项目之前，有没有看过这个方向上已经有什么成熟方案？你自己的项目跟它们差在哪里？

这个问题的难点，不是让你去做一份竞品分析。而是看你有没有基本的判断力和对新技术的敏感度。

比如你做 code agent，面试官很容易问到：

你了解过 Claude Code、OpenCode 这些东西吗？
你这个项目跟它们相比，差异到底在哪？

如果你做的是更通用的 Agent，也可能会被问到：

你有没有看过 OpenClaw、Hermes 这一类方案？
你自己的项目重点放在哪？
你和这些系统相比，到底少了什么，多了什么，或者你更关注哪一层？

以后大家去实习工作了，一个新项目的落地肯定也逃不过这个问题。你能不能把自己的项目放回到整个生态里去看，面试官就是在提前考察你有没有这样的敏感度。

如果你只会说”我自己做了一个 Agent”，那项目很容易显得视野太窄。但如果你能讲清楚：

这个方向上已经有谁在做
它们分别强在哪
你的项目为什么不跟它们比功能广度
你自己这一版重点想讲清楚的到底是哪一层

那会让面试官眼前一亮的。

为什么我觉得 code agent 特别适合校招面试？#

如果要让我推荐一个业务方向，来让项目天然更容易引发面试官继续问，code agent 确实是个很适合讲的垂直方向。

它天然就能把很多面试官会继续深问的东西带出来：

工具
状态
上下文
memory
评测

这些点你只要能讲顺两三层，项目就不只是一个热点词，而更像一个能扛追问的工程项目。也正因为这样，我最后才会选这个方向，自己做了 pico 这个项目。

附：Pico 项目简历描述示例#

Pico: 本地代码智能体 Harness

核心技术： Python、Agent Harness、Tool Calling、Context Engineering、Memory Retrieval、Prompt Cache

项目描述： 面向代码仓库长链路任务开发本地代码 Agent Harness，覆盖模型接入、工具调用、上下文管理、结构化记忆、运行审计与评测闭环，重点解决多轮任务中的上下文膨胀、重复读取、工具误调用和结果不可复现问题

核心工作：

Agent Harness 架构设计：负责本地代码 Agent 的整体设计与开发，统一模型接入、工具执行、会话状态和运行工件落盘流程，形成可回放的任务执行链路；支持 2 类模型后端、7 类工具和 3 类运行工件。
长上下文治理：针对代码仓库长链路任务中的 prompt 膨胀问题，设计分层上下文管理与预算裁剪机制；在 12 组真实长上下文配置上，将平均 prompt 长度从 6964 压缩到 5418，平均压缩率 18.01%，最高压缩率 35.63%。
结构化记忆系统：将任务摘要、文件摘要和会话笔记分层管理，并结合 freshness 校验和相关记忆召回减少重复读取；在 12 个真实记忆依赖任务中，将重复读文件次数从 8 次降到 3 次，平均工具步数从 0.67 降到 0.25，任务正确率从 66.7% 提升到 100%。
工具安全与运行治理：构建标准化工具调用与安全边界，覆盖参数校验、工作区隔离、高风险审批、只读委派、重复调用拦截和敏感信息脱敏；在 1 个真实治理场景中，结构化记录 3 次路径选择拦截、5 次无效参数拒绝和 2 次重复调用拦截。
评测与审计闭环：建立固定 benchmark 与运行审计体系，支持 pass_rate / attempts / tool_steps / failure_category / trace 的自动汇总与回归对比；当前覆盖 6 个标准化任务和 86 条自动化测试。
模型后端效果评估：搭建 GPT / Claude provider 分离对比框架，在 GPT 后端的 6 个固定任务上取得 83.33% 的 pass rate，平均 attempts=3.00、平均 tool_steps=2.00，支撑不同模型后端的效果与成本评估。

我想做的，不是一个为了炫技的 Agent demo，是一个真正方便大家拿去研究、包装、写进简历、准备面试的项目。

现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑整理

Wed, 10 Jun 2026 00:00:00 GMT

现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑#

问题#

现场实操：给定一个包含数据Schema的API文档，请使用AI工具？ 15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑

标准回答#

现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-Base URL:https://api.example.com/v1-数据格式: JSON-认证方式: Bearer Token (需在Header中添加Authorization: Bearer <token>)

---## 数据结构 Schema### Todo 对象| 字段名 | 类型 | 必填 | 描述 |

|--------------|---------|------|--------------------------|

|id| string | 是 | 唯一标识符 (UUIDv4) |

---## API 接口列表### 1. 获取Todo列表GET/todos#### 参数| 参数名 | 类型 | 默认值 | 描述 |

|------------|---------|--------|--------------------------|

{

“total”: 45,

“page”: 1,

“limit”: 20,

“items”: [

{

“id”: “550e8400-e29b-41d4-a716-446655440000”,

“title”: “购买食材”,

“status”: “pending”,

“dueDate”: “2025-03-30T09:00:00Z”,

“createdAt”: “2025-03-28T14:30:00Z”

}

]

}

2. 创建新Todo#

POST /todos

请求体#

1
{
2

3
"title": "项目会议准备",
4

5
"description": "准备季度项目汇报材料",
6

7
"dueDate": "2025-04-01T14:00:00Z"
8

9
}` ``#### 响应 (201 Created)```json
10

11
{
12

13
"id": "550e8400-e29b-41d4-a716-446655440000",
14

15
"title": "项目会议准备",
16

17
"status": "pending",
18

19
"dueDate": "2025-04-01T14:00:00Z",
20

21
"createdAt": "2025-03-28T15:00:00Z"
22

23
}
24

25
` ` `
26

27
---
28

29
### 3. 获取单个Todo详情
30

31
**GET** `/todos/{id}`
32

33
#### 响应示例
34

35
```json
36

37
{
38

39
"id": "550e8400-e29b-41d4-a716-446655440000",
40

41
"title": "项目会议准备",
42

43
"description": "准备季度项目汇报材料",
44

45
"status": "pending",
46

47
"dueDate": "2025-04-01T14:00:00Z",
48

49
"createdAt": "2025-03-28T15:00:00Z",
50

51
"updatedAt": "2025-03-28T15:00:00Z"
52

53
}` ``
54

55
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
56

57
{
58

59
"title": "更新后的会议准备",
60

61
"status": "completed"
62

63
}
64

65
` ` `
66

67
#### 响应
68

69
```json
70

71
{
72

73
"id": "550e8400-e29b-41d4-a716-446655440000",
74

75
"title": "更新后的会议准备",
76

77
"status": "completed",
78

79
"updatedAt": "2025-03-28T16:00:00Z"
80

81
}` ``
82

83
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
84

85
{
86

87
"ids": ["id1", "id2"],
88

89
"status": "completed"
90

91
}
92

93
` ` `
94

95
#### 响应
96

97
```json
98

99
{
100

101
"updatedCount": 2
102

103
}` ``
104

105
---## 错误处理| 状态码 | 描述                  |
106

107
|--------|-----------------------|
108

109
| 400    | 请求参数验证失败      |
110

111
| 401    | 未授权访问            |
112

113
| 404    | 资源不存在            |
114

115
| 429    | 请求频率限制          |
116

117
| 500    | 服务器内部错误        |
118

119
错误响应示例：```json
120

121
{
122

123
"error": {
124

125
"code": "INVALID_DUE_DATE",
126

127
"message": "截止日期不能早于当前时间"
128

129
}
130

131
}
132

133
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
134

135
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
136

137
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
138

139
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
140

141
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
142

143
userService.delete(id);returnResult.success(null);
144

145
}
146

147
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
148

149
## 扩展知识
150

151
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
152

153
## 面试官追问
154

155
- **提问**：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？回答：拿到代码第一件事就是扫一遍安全问题。如果发现有 SQL 拼接这种明显漏洞，直接手动改成参数化查询。如果是鉴权没做，补上@PreAuthorize或者自定义拦截器。改完之后会反向给 AI 一个反馈，告诉它下次要注意这个点，后续生成的代码质量会提升。- **提问**：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？
156
- **回答**：PUT 是全量更新，客户端得把所有字段都传过来，没传的字段会被置空。PATCH 是部分更新，只更新传了的字段。实际项目里 PATCH 用得更多，因为前端很少会一次性改全部字段。生成代码时如果是编辑场景，优先用 PATCH 加一个非空校验逻辑。- **提问**：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？
157
- **回答**：优先级是安全 > 正确性 > 规范性。第一改安全漏洞，比如 SQL 注入、越权访问。第二改逻辑错误，比如空指针、边界条件没处理。第三才是代码风格、命名规范这些。规范性的问题不影响功能，面试完再改也行。
158

159
Prompt 优化技巧生成代码的 Review 重点不同 AI 工具的差异面试现场实操建议
160

161
提问：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？提问：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？提问：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号
162

163
## 答案
164

165
设计智能客服系统时，如何通过知识库构建解决长尾问题？请描述具体实现步骤当大模型API响应延迟超过1秒时，前端可以采取哪些优化策略保证用户体验？上次浏览：2026-03-16 15:08:14使用LangChain时，如何实现多路召回结果的动态权重分配？上次浏览：2026-03-16 15:09:02当大模型上下文窗口扩展到100万token时，哪些现有业务场景可能发生质变？当发现RAG系统召回结果与用户query意图不匹配时，有哪些可能的改进方向？使用LangChain实现RAG系统时，如何处理PDF文档中的表格数据召回问题？现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑参数高效微调（PEFT）如何减少计算成本？冻结层在微调中的作用是什么？为什么需要混合精度训练？上次浏览：2026-03-16 15:09:27模型输出重复和幻觉如何微调解决？上次浏览：2026-03-16 15:10:0511345. 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
166

167
---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
168

169
|--------------|---------|------|--------------------------|
170

171
|`id`| string  | 是   | 唯一标识符 (UUIDv4)      |
172

173
|`title`| string  | 是   | 任务标题 (1-100字符)     |
174

175
|`description`| string  | 否   | 任务描述 (可选)          |
176

177
|`status`| enum    | 是   |`pending`/`completed`|
178

179
|`dueDate`| string  | 否   | 截止日期 (ISO8601格式)   |
180

181
|`createdAt`| string  | 是   | 创建时间 (ISO8601格式)   |
182

183
|`updatedAt`| string  | 是   | 最后更新时间 (ISO8601)   |
184

185
---## API 接口列表### 1. 获取Todo列表**GET**`/todos`#### 参数| 参数名     | 类型    | 默认值 | 描述                     |
186

187
|------------|---------|--------|--------------------------|
188

189
|`status`| string  | -      | 过滤状态 (`pending/completed`) |
190

191
|`page`| integer | 1      | 分页页码                 |
192

193
|`limit`| integer | 20     | 每页数量 (最大100)       |#### 响应示例```json
194

195
{
196

197
"total": 45,
198

199
"page": 1,
200

201
"limit": 20,
202

203
"items": [
204

205
{
206

207
"id": "550e8400-e29b-41d4-a716-446655440000",
208

209
"title": "购买食材",
210

211
"status": "pending",
212

213
"dueDate": "2025-03-30T09:00:00Z",
214

215
"createdAt": "2025-03-28T14:30:00Z"
216

217
}
218

219
]
220

221
}
222

223
` ` `
224

225
---
226

227
**POST** `/todos`
228

229
#### 请求体
230

231
```json
232

233
{
234

235
"title": "项目会议准备",
236

237
"description": "准备季度项目汇报材料",
238

239
"dueDate": "2025-04-01T14:00:00Z"
240

241
}` ``#### 响应 (201 Created)```json
242

243
{
244

245
"id": "550e8400-e29b-41d4-a716-446655440000",
246

247
"title": "项目会议准备",
248

249
"status": "pending",
250

251
"dueDate": "2025-04-01T14:00:00Z",
252

253
"createdAt": "2025-03-28T15:00:00Z"
254

255
}
256

257
` ` `
258

259
---
260

261
**GET** `/todos/{id}`
262

263
#### 响应示例
264

265
```json
266

267
{
268

269
"id": "550e8400-e29b-41d4-a716-446655440000",
270

271
"title": "项目会议准备",
272

273
"description": "准备季度项目汇报材料",
274

275
"status": "pending",
276

277
"dueDate": "2025-04-01T14:00:00Z",
278

279
"createdAt": "2025-03-28T15:00:00Z",
280

281
"updatedAt": "2025-03-28T15:00:00Z"
282

283
}` ``
284

285
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
286

287
{
288

289
"title": "更新后的会议准备",
290

291
"status": "completed"
292

293
}
294

295
` ` `
296

297
#### 响应
298

299
```json
300

301
{
302

303
"id": "550e8400-e29b-41d4-a716-446655440000",
304

305
"title": "更新后的会议准备",
306

307
"status": "completed",
308

309
"updatedAt": "2025-03-28T16:00:00Z"
310

311
}` ``
312

313
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
314

315
{
316

317
"ids": ["id1", "id2"],
318

319
"status": "completed"
320

321
}
322

323
` ` `
324

325
#### 响应
326

327
```json
328

329
{
330

331
"updatedCount": 2
332

333
}` ``
334

335
---## 错误处理| 状态码 | 描述                  |
336

337
|--------|-----------------------|
338

339
| 400    | 请求参数验证失败      |
340

341
| 401    | 未授权访问            |
342

343
| 404    | 资源不存在            |
344

345
| 429    | 请求频率限制          |
346

347
| 500    | 服务器内部错误        |
348

349
错误响应示例：```json
350

351
{
352

353
"error": {
354

355
"code": "INVALID_DUE_DATE",
356

357
"message": "截止日期不能早于当前时间"
358

359
}
360

361
}
362

363
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
364

365
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
366

367
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
368

369
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
370

371
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
372

373
userService.delete(id);returnResult.success(null);
374

375
}
376

377
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
378

379
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
380

381
- **提问**：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？回答：拿到代码第一件事就是扫一遍安全问题。如果发现有 SQL 拼接这种明显漏洞，直接手动改成参数化查询。如果是鉴权没做，补上@PreAuthorize或者自定义拦截器。改完之后会反向给 AI 一个反馈，告诉它下次要注意这个点，后续生成的代码质量会提升。- **提问**：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？
382
- **回答**：PUT 是全量更新，客户端得把所有字段都传过来，没传的字段会被置空。PATCH 是部分更新，只更新传了的字段。实际项目里 PATCH 用得更多，因为前端很少会一次性改全部字段。生成代码时如果是编辑场景，优先用 PATCH 加一个非空校验逻辑。- **提问**：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？
383
- **回答**：优先级是安全 > 正确性 > 规范性。第一改安全漏洞，比如 SQL 注入、越权访问。第二改逻辑错误，比如空指针、边界条件没处理。第三才是代码风格、命名规范这些。规范性的问题不影响功能，面试完再改也行。
384

385
Prompt 优化技巧生成代码的 Review 重点不同 AI 工具的差异面试现场实操建议
386

387
提问：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？提问：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？提问：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号
388

389
---
390

391
> 来源: 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑.mhtml
392

393
##
394

395
## 关键点
396

397
- # 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑
398
现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
399

400
---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
401

402
|--------------|---------|------|--------------------------|
403

404
|`id`| string  | 是   | 唯一标识符 (UUIDv4)      |
405

406
|`title`| string  | 是   | 任务标题 (1-100字符)     |
407

408
|`description`| string  | 否   | 任务描述 (可选)          |
409

410
|`status`| enum    | 是   |`pending`/`completed`|
411

412
|`dueDate`| string  | 否   | 截止日期 (ISO8601格式)   |
413

414
|`createdAt`| string  | 是   | 创建时间 (ISO8601格式)   |
415

416
|`updatedAt`| string  | 是   | 最后更新时间 (ISO8601)   |
417

418
---## API 接口列表### 1. 获取Todo列表**GET**`/todos`#### 参数| 参数名     | 类型    | 默认值 | 描述                     |
419

420
|------------|---------|--------|--------------------------|
421

422
|`status`| string  | -      | 过滤状态 (`pending/completed`) |
423

424
|`page`| integer | 1      | 分页页码                 |
425

426
|`limit`| integer | 20     | 每页数量 (最大100)       |#### 响应示例```json
427

428
{
429

430
"total": 45,
431

432
"page": 1,
433

434
"limit": 20,
435

436
"items": [
437

438
{
439

440
"id": "550e8400-e29b-41d4-a716-446655440000",
441

442
"title": "购买食材",
443

444
"status": "pending",
445

446
"dueDate": "2025-03-30T09:00:00Z",
447

448
"createdAt": "2025-03-28T14:30:00Z"
449

450
}
451

452
]
453

454
}
455

456
` ` `
457

458
---
459

460
**POST** `/todos`
461

462
#### 请求体
463

464
```json
465

466
{
467

468
"title": "项目会议准备",
469

470
"description": "准备季度项目汇报材料",
471

472
"dueDate": "2025-04-01T14:00:00Z"
473

474
}` ``#### 响应 (201 Created)```json
475

476
{
477

478
"id": "550e8400-e29b-41d4-a716-446655440000",
479

480
"title": "项目会议准备",
481

482
"status": "pending",
483

484
"dueDate": "2025-04-01T14:00:00Z",
485

486
"createdAt": "2025-03-28T15:00:00Z"
487

488
}
489

490
` ` `
491

492
---
493

494
**GET** `/todos/{id}`
495

496
#### 响应示例
497

498
```json
499

500
{
501

502
"id": "550e8400-e29b-41d4-a716-446655440000",
503

504
"title": "项目会议准备",
505

506
"description": "准备季度项目汇报材料",
507

508
"status": "pending",
509

510
"dueDate": "2025-04-01T14:00:00Z",
511

512
"createdAt": "2025-03-28T15:00:00Z",
513

514
"updatedAt": "2025-03-28T15:00:00Z"
515

516
}` ``
517

518
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
519

520
{
521

522
"title": "更新后的会议准备",
523

524
"status": "completed"
525

526
}
527

528
` ` `
529

530
#### 响应
531

532
```json
533

534
{
535

536
"id": "550e8400-e29b-41d4-a716-446655440000",
537

538
"title": "更新后的会议准备",
539

540
"status": "completed",
541

542
"updatedAt": "2025-03-28T16:00:00Z"
543

544
}` ``
545

546
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
547

548
{
549

550
"ids": ["id1", "id2"],
551

552
"status": "completed"
553

554
}
555

556
` ` `
557

558
#### 响应
559

560
```json
561

562
{
563

564
"updatedCount": 2
565

566
}` ``
567

568
---## 错误处理| 状态码 | 描述                  |
569

570
|--------|-----------------------|
571

572
| 400    | 请求参数验证失败      |
573

574
| 401    | 未授权访问            |
575

576
| 404    | 资源不存在            |
577

578
| 429    | 请求频率限制          |
579

580
| 500    | 服务器内部错误        |
581

582
错误响应示例：```json
583

584
{
585

586
"error": {
587

588
"code": "INVALID_DUE_DATE",
589

590
"message": "截止日期不能早于当前时间"
591

592
}
593

594
}
595

596
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。
597
- 整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
598

599
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
600

601
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
602

603
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
604

605
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
606

607
userService.delete(id);returnResult.success(null);
608

609
}
610

611
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
612
-
613

614
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。
615
- AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。
616
- 一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
617

618
## 备注
619

620
- 本文已做格式统一与噪声清理，保留原始语义。
621
- ## 问题
622

623
现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑
624
现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
625

626
---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
627

628
|--------------|---------|------|--------------------------|
629

630
|`id`| string  | 是   | 唯一标识符 (UUIDv4)      |
631

632
|`title`| string  | 是   | 任务标题 (1-100字符)     |
633

634
|`description`| string  | 否   | 任务描述 (可选)          |
635

636
|`status`| enum    | 是   |`pending`/`completed`|
637

638
|`dueDate`| string  | 否   | 截止日期 (ISO8601格式)   |
639

640
|`createdAt`| string  | 是   | 创建时间 (ISO8601格式)   |
641

642
|`updatedAt`| string  | 是   | 最后更新时间 (ISO8601)   |
643

644
---## API 接口列表### 1. 获取Todo列表**GET**`/todos`#### 参数| 参数名     | 类型    | 默认值 | 描述                     |
645

646
|------------|---------|--------|--------------------------|
647

648
|`status`| string  | -      | 过滤状态 (`pending/completed`) |
649

650
|`page`| integer | 1      | 分页页码                 |
651

652
|`limit`| integer | 20     | 每页数量 (最大100)       |#### 响应示例```json
653

654
{
655

656
"total": 45,
657

658
"page": 1,
659

660
"limit": 20,
661

662
"items": [
663

664
{
665

666
"id": "550e8400-e29b-41d4-a716-446655440000",
667

668
"title": "购买食材",
669

670
"status": "pending",
671

672
"dueDate": "2025-03-30T09:00:00Z",
673

674
"createdAt": "2025-03-28T14:30:00Z"
675

676
}
677

678
]
679

680
}
681

682
` ` `
683

684
---
685

686
**POST** `/todos`
687

688
#### 请求体
689

690
```json
691

692
{
693

694
"title": "项目会议准备",
695

696
"description": "准备季度项目汇报材料",
697

698
"dueDate": "2025-04-01T14:00:00Z"
699

700
}` ``#### 响应 (201 Created)```json
701

702
{
703

704
"id": "550e8400-e29b-41d4-a716-446655440000",
705

706
"title": "项目会议准备",
707

708
"status": "pending",
709

710
"dueDate": "2025-04-01T14:00:00Z",
711

712
"createdAt": "2025-03-28T15:00:00Z"
713

714
}
715

716
` ` `
717

718
---
719

720
**GET** `/todos/{id}`
721

722
#### 响应示例
723

724
```json
725

726
{
727

728
"id": "550e8400-e29b-41d4-a716-446655440000",
729

730
"title": "项目会议准备",
731

732
"description": "准备季度项目汇报材料",
733

734
"status": "pending",
735

736
"dueDate": "2025-04-01T14:00:00Z",
737

738
"createdAt": "2025-03-28T15:00:00Z",
739

740
"updatedAt": "2025-03-28T15:00:00Z"
741

742
}` ``
743

744
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
745

746
{
747

748
"title": "更新后的会议准备",
749

750
"status": "completed"
751

752
}
753

754
` ` `
755

756
#### 响应
757

758
```json
759

760
{
761

762
"id": "550e8400-e29b-41d4-a716-446655440000",
763

764
"title": "更新后的会议准备",
765

766
"status": "completed",
767

768
"updatedAt": "2025-03-28T16:00:00Z"
769

770
}` ``
771

772
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
773

774
{
775

776
"ids": ["id1", "id2"],
777

778
"status": "completed"
779

780
}
781

782
` ` `
783

784
#### 响应
785

786
```json
787

788
{
789

790
"updatedCount": 2
791

792
}` ``
793

794
---## 错误处理| 状态码 | 描述                  |
795

796
|--------|-----------------------|
797

798
| 400    | 请求参数验证失败      |
799

800
| 401    | 未授权访问            |
801

802
| 404    | 资源不存在            |
803

804
| 429    | 请求频率限制          |
805

806
| 500    | 服务器内部错误        |
807

808
错误响应示例：```json
809

810
{
811

812
"error": {
813

814
"code": "INVALID_DUE_DATE",
815

816
"message": "截止日期不能早于当前时间"
817

818
}
819

820
}
821

822
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
823

824
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
825

826
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
827

828
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
829

830
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
831

832
userService.delete(id);returnResult.success(null);
833

834
}
835

836
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
837

838
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
839

840
- **提问**：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？回答：拿到代码第一件事就是扫一遍安全问题。如果发现有 SQL 拼接这种明显漏洞，直接手动改成参数化查询。如果是鉴权没做，补上@PreAuthorize或者自定义拦截器。改完之后会反向给 AI 一个反馈，告诉它下次要注意这个点，后续生成的代码质量会提升。- **提问**：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？
841
- **回答**：PUT 是全量更新，客户端得把所有字段都传过来，没传的字段会被置空。PATCH 是部分更新，只更新传了的字段。实际项目里 PATCH 用得更多，因为前端很少会一次性改全部字段。生成代码时如果是编辑场景，优先用 PATCH 加一个非空校验逻辑。- **提问**：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？
842
- **回答**：优先级是安全 > 正确性 > 规范性。第一改安全漏洞，比如 SQL 注入、越权访问。第二改逻辑错误，比如空指针、边界条件没处理。第三才是代码风格、命名规范这些。规范性的问题不影响功能，面试完再改也行。
843

844
Prompt 优化技巧生成代码的 Review 重点不同 AI 工具的差异面试现场实操建议
845

846
提问：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？提问：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？提问：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号
847

848
设计智能客服系统时，如何通过知识库构建解决长尾问题？请描述具体实现步骤当大模型API响应延迟超过1秒时，前端可以采取哪些优化策略保证用户体验？上次浏览：2026-03-16 15:08:14使用LangChain时，如何实现多路召回结果的动态权重分配？上次浏览：2026-03-16 15:09:02当大模型上下文窗口扩展到100万token时，哪些现有业务场景可能发生质变？当发现RAG系统召回结果与用户query意图不匹配时，有哪些可能的改进方向？使用LangChain实现RAG系统时，如何处理PDF文档中的表格数据召回问题？现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑参数高效微调（PEFT）如何减少计算成本？冻结层在微调中的作用是什么？为什么需要混合精度训练？上次浏览：2026-03-16 15:09:27模型输出重复和幻觉如何微调解决？上次浏览：2026-03-16 15:10:0511345. 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
849

850
---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
851

852
|--------------|---------|------|--------------------------|
853

854
|`id`| string  | 是   | 唯一标识符 (UUIDv4)      |
855

856
|`title`| string  | 是   | 任务标题 (1-100字符)     |
857

858
|`description`| string  | 否   | 任务描述 (可选)          |
859

860
|`status`| enum    | 是   |`pending`/`completed`|
861

862
|`dueDate`| string  | 否   | 截止日期 (ISO8601格式)   |
863

864
|`createdAt`| string  | 是   | 创建时间 (ISO8601格式)   |
865

866
|`updatedAt`| string  | 是   | 最后更新时间 (ISO8601)   |
867

868
---## API 接口列表### 1. 获取Todo列表**GET**`/todos`#### 参数| 参数名     | 类型    | 默认值 | 描述                     |
869

870
|------------|---------|--------|--------------------------|
871

872
|`status`| string  | -      | 过滤状态 (`pending/completed`) |
873

874
|`page`| integer | 1      | 分页页码                 |
875

876
|`limit`| integer | 20     | 每页数量 (最大100)       |#### 响应示例```json
877

878
{
879

880
"total": 45,
881

882
"page": 1,
883

884
"limit": 20,
885

886
"items": [
887

888
{
889

890
"id": "550e8400-e29b-41d4-a716-446655440000",
891

892
"title": "购买食材",
893

894
"status": "pending",
895

896
"dueDate": "2025-03-30T09:00:00Z",
897

898
"createdAt": "2025-03-28T14:30:00Z"
899

900
}
901

902
]
903

904
}
905

906
` ` `
907

908
---
909

910
**POST** `/todos`
911

912
#### 请求体
913

914
```json
915

916
{
917

918
"title": "项目会议准备",
919

920
"description": "准备季度项目汇报材料",
921

922
"dueDate": "2025-04-01T14:00:00Z"
923

924
}` ``#### 响应 (201 Created)```json
925

926
{
927

928
"id": "550e8400-e29b-41d4-a716-446655440000",
929

930
"title": "项目会议准备",
931

932
"status": "pending",
933

934
"dueDate": "2025-04-01T14:00:00Z",
935

936
"createdAt": "2025-03-28T15:00:00Z"
937

938
}
939

940
` ` `
941

942
---
943

944
**GET** `/todos/{id}`
945

946
#### 响应示例
947

948
```json
949

950
{
951

952
"id": "550e8400-e29b-41d4-a716-446655440000",
953

954
"title": "项目会议准备",
955

956
"description": "准备季度项目汇报材料",
957

958
"status": "pending",
959

960
"dueDate": "2025-04-01T14:00:00Z",
961

962
"createdAt": "2025-03-28T15:00:00Z",
963

964
"updatedAt": "2025-03-28T15:00:00Z"
965

966
}` ``
967

968
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
969

970
{
971

972
"title": "更新后的会议准备",
973

974
"status": "completed"
975

976
}
977

978
` ` `
979

980
#### 响应
981

982
```json
983

984
{
985

986
"id": "550e8400-e29b-41d4-a716-446655440000",
987

988
"title": "更新后的会议准备",
989

990
"status": "completed",
991

992
"updatedAt": "2025-03-28T16:00:00Z"
993

994
}` ``
995

996
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
997

998
{
999

1000
"ids": ["id1", "id2"],
1001

1002
"status": "completed"
1003

1004
}
1005

1006
` ` `
1007

1008
#### 响应
1009

1010
```json
1011

1012
{
1013

1014
"updatedCount": 2
1015

1016
}` ``
1017

1018
---## 错误处理| 状态码 | 描述                  |
1019

1020
|--------|-----------------------|
1021

1022
| 400    | 请求参数验证失败      |
1023

1024
| 401    | 未授权访问            |
1025

1026
| 404    | 资源不存在            |
1027

1028
| 429    | 请求频率限制          |
1029

1030
| 500    | 服务器内部错误        |
1031

1032
错误响应示例：```json
1033

1034
{
1035

1036
"error": {
1037

1038
"code": "INVALID_DUE_DATE",
1039

1040
"message": "截止日期不能早于当前时间"
1041

1042
}
1043

1044
}
1045

1046
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
1047

1048
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
1049

1050
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
1051

1052
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
1053

1054
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
1055

1056
userService.delete(id);returnResult.success(null);
1057

1058
}
1059

1060
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
1061

1062
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
1063

1064
- **提问**：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？回答：拿到代码第一件事就是扫一遍安全问题。如果发现有 SQL 拼接这种明显漏洞，直接手动改成参数化查询。如果是鉴权没做，补上@PreAuthorize或者自定义拦截器。改完之后会反向给 AI 一个反馈，告诉它下次要注意这个点，后续生成的代码质量会提升。- **提问**：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？
1065
- **回答**：PUT 是全量更新，客户端得把所有字段都传过来，没传的字段会被置空。PATCH 是部分更新，只更新传了的字段。实际项目里 PATCH 用得更多，因为前端很少会一次性改全部字段。生成代码时如果是编辑场景，优先用 PATCH 加一个非空校验逻辑。- **提问**：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？
1066
- **回答**：优先级是安全 > 正确性 > 规范性。第一改安全漏洞，比如 SQL 注入、越权访问。第二改逻辑错误，比如空指针、边界条件没处理。第三才是代码风格、命名规范这些。规范性的问题不影响功能，面试完再改也行。
1067

1068
Prompt 优化技巧生成代码的 Review 重点不同 AI 工具的差异面试现场实操建议
1069

1070
提问：如果 AI 生成的代码有明显的安全漏洞，你会怎么处理？提问：RESTful 规范里 PUT 和 PATCH 有什么区别，生成代码时要怎么选？提问：如果时间来不及，AI 生成的代码只来得及做部分修改，你会优先改哪里？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号
1071

1072
---
1073

1074
> 来源: 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑.mhtml
1075

1076
- # 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑
1077
现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
1078

1079
---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
1080

1081
|--------------|---------|------|--------------------------|
1082

1083
|`id`| string  | 是   | 唯一标识符 (UUIDv4)      |
1084

1085
|`title`| string  | 是   | 任务标题 (1-100字符)     |
1086

1087
|`description`| string  | 否   | 任务描述 (可选)          |
1088

1089
|`status`| enum    | 是   |`pending`/`completed`|
1090

1091
|`dueDate`| string  | 否   | 截止日期 (ISO8601格式)   |
1092

1093
|`createdAt`| string  | 是   | 创建时间 (ISO8601格式)   |
1094

1095
|`updatedAt`| string  | 是   | 最后更新时间 (ISO8601)   |
1096

1097
---## API 接口列表### 1. 获取Todo列表**GET**`/todos`#### 参数| 参数名     | 类型    | 默认值 | 描述                     |
1098

1099
|------------|---------|--------|--------------------------|
1100

1101
|`status`| string  | -      | 过滤状态 (`pending/completed`) |
1102

1103
|`page`| integer | 1      | 分页页码                 |
1104

1105
|`limit`| integer | 20     | 每页数量 (最大100)       |#### 响应示例```json
1106

1107
{
1108

1109
"total": 45,
1110

1111
"page": 1,
1112

1113
"limit": 20,
1114

1115
"items": [
1116

1117
{
1118

1119
"id": "550e8400-e29b-41d4-a716-446655440000",
1120

1121
"title": "购买食材",
1122

1123
"status": "pending",
1124

1125
"dueDate": "2025-03-30T09:00:00Z",
1126

1127
"createdAt": "2025-03-28T14:30:00Z"
1128

1129
}
1130

1131
]
1132

1133
}
1134

1135
` ` `
1136

1137
---
1138

1139
**POST** `/todos`
1140

1141
#### 请求体
1142

1143
```json
1144

1145
{
1146

1147
"title": "项目会议准备",
1148

1149
"description": "准备季度项目汇报材料",
1150

1151
"dueDate": "2025-04-01T14:00:00Z"
1152

1153
}` ``#### 响应 (201 Created)```json
1154

1155
{
1156

1157
"id": "550e8400-e29b-41d4-a716-446655440000",
1158

1159
"title": "项目会议准备",
1160

1161
"status": "pending",
1162

1163
"dueDate": "2025-04-01T14:00:00Z",
1164

1165
"createdAt": "2025-03-28T15:00:00Z"
1166

1167
}
1168

1169
` ` `
1170

1171
---
1172

1173
**GET** `/todos/{id}`
1174

1175
#### 响应示例
1176

1177
```json
1178

1179
{
1180

1181
"id": "550e8400-e29b-41d4-a716-446655440000",
1182

1183
"title": "项目会议准备",
1184

1185
"description": "准备季度项目汇报材料",
1186

1187
"status": "pending",
1188

1189
"dueDate": "2025-04-01T14:00:00Z",
1190

1191
"createdAt": "2025-03-28T15:00:00Z",
1192

1193
"updatedAt": "2025-03-28T15:00:00Z"
1194

1195
}` ``
1196

1197
---### 4. 更新Todo信息**PATCH**`/todos/{id}`#### 请求体 (部分更新)```json
1198

1199
{
1200

1201
"title": "更新后的会议准备",
1202

1203
"status": "completed"
1204

1205
}
1206

1207
` ` `
1208

1209
#### 响应
1210

1211
```json
1212

1213
{
1214

1215
"id": "550e8400-e29b-41d4-a716-446655440000",
1216

1217
"title": "更新后的会议准备",
1218

1219
"status": "completed",
1220

1221
"updatedAt": "2025-03-28T16:00:00Z"
1222

1223
}` ``
1224

1225
---### 5. 删除Todo**DELETE**`/todos/{id}`#### 响应 (204 No Content)---### 6. 批量更新状态**POST**`/todos/batch-update`#### 请求体```json
1226

1227
{
1228

1229
"ids": ["id1", "id2"],
1230

1231
"status": "completed"
1232

1233
}
1234

1235
` ` `
1236

1237
#### 响应
1238

1239
```json
1240

1241
{
1242

1243
"updatedCount": 2
1244

1245
}` ``
1246

1247
---## 错误处理| 状态码 | 描述                  |
1248

1249
|--------|-----------------------|
1250

1251
| 400    | 请求参数验证失败      |
1252

1253
| 401    | 未授权访问            |
1254

1255
| 404    | 资源不存在            |
1256

1257
| 429    | 请求频率限制          |
1258

1259
| 500    | 服务器内部错误        |
1260

1261
错误响应示例：```json
1262

1263
{
1264

1265
"error": {
1266

1267
"code": "INVALID_DUE_DATE",
1268

1269
"message": "截止日期不能早于当前时间"
1270

1271
}
1272

1273
}
1274

1275
` ` `标记分享51006这道实操题考察的是Prompt 工程能力和对 RESTful 规范的理解，核心思路是把 Schema 喂给 AI，再通过结构化 Prompt 引导它生成标准 CRUD 代码。
1276
- - 整个操作流程分 3 步：1）先把 API 文档里的 Schema 提取出来，比如一个用户表有 id、name、email、created_at 这些字段2）构造一个精准的 Prompt，明确告诉 AI 要用什么框架、遵循什么规范、返回什么格式3）拿到生成的代码后快速 review，重点看路由设计、参数校验、异常处理这几块假设 Schema 是这样的：▼json复制代码{"User":{"id":"long, 主键","name":"string, 必填, 最大50字符","email":"string, 必填, 邮箱格式","created_at":"datetime, 自动生成"}}给 AI 的 Prompt 可以这样写：▼text复制代码基于以下 Schema 生成 Spring Boot 的 RESTful CRUD 接口：-框架：Spring Boot 3.x + Spring Data JPA-规范：严格遵循 RESTful，GET 用于查询，POST 用于创建，PUT 用于全量更新，DELETE 用于删除-响应格式：统一包装成 {code, message, data} 结构-要求：包含参数校验注解、异常处理Schema:
1277

1278
{粘贴上面的 JSON}AI 生成的 Controller 核心代码大概长这样：▼java复制代码@RestController@RequestMapping("/api/users")publicclassUserController{@AutowiredprivateUserService userService;@GetMapping("/{id}")publicResult<User>getById(@PathVariableLong id){returnResult.success(userService.findById(id));
1279

1280
}@PostMappingpublicResult<User>create(@Valid@RequestBodyUserCreateDTO dto){returnResult.success(userService.create(dto));
1281

1282
}@PutMapping("/{id}")publicResult<User>update(@PathVariableLong id,@Valid@RequestBodyUserUpdateDTO dto){returnResult.success(userService.update(id, dto));
1283

1284
}@DeleteMapping("/{id}")publicResult<Void>delete(@PathVariableLong id){
1285

1286
userService.delete(id);returnResult.success(null);
1287

1288
}
1289

1290
}拿到代码后重点检查这几个地方：路由是不是用了复数名词、HTTP 方法用得对不对、有没有加@Valid做参数校验。
1291
- -
1292

1293
Prompt 优化技巧很多人用 AI 生成代码效果不好，问题往往出在 Prompt 太模糊。
1294
- - AI 不是人，它猜不到你想要 Spring Boot 还是 Express，猜不到你们公司用的是驼峰还是下划线命名。
1295
- - 一个高质量的 Prompt 要包含 4 个要素：1）技术栈版本，比如 Spring Boot 3.2、JDK 17、MyBatis Plus 3.52）编码规范，比如 RESTful 风格、统一响应体结构、驼峰命名3）完整上下文，Schema 要全贴上去，字段类型、约束条件一个都不能少4）反例约束，告诉 AI 不要干什么，比如"不要用 Lombok"、"不要用 XML 配置"生成代码的 Review 重点AI 生成的代码不能直接用，至少要检查这几个地方：1）安全性漏洞，有没有 SQL 注入风险、有没有做权限校验2）异常处理是不是完善，空指针、资源不存在这些边界情况覆盖了没有3）事务边界对不对，涉及多表操作的有没有加@Transactional4）日志是不是规范，关键操作有没有打日志，日志级别用得对不对不同 AI 工具的差异现在市面上 AI 编程工具很多，Cursor、GitHub Copilot、通义灵码、CodeGeeX 各有特点：工具强项弱项Cursor上下文理解强，能读懂整个项目收费，国内网络不稳定Copilot补全速度快，和 IDE 集成好对中文注释理解一般通义灵码中文支持好，免费额度多复杂逻辑生成质量不如前两者CodeGeeX完全免费，国产模型偶尔会生成过时 API面试现场实操建议15 分钟时间很紧，建议这样分配：1）前 3 分钟，快速阅读 Schema，理解业务含义，想清楚要生成哪些接口2）中间 8 分钟，写 Prompt、喂给 AI、拿到代码、快速调整明显问题3）最后 4 分钟，给面试官讲解代码结构和设计决策，展示你的工程思维关键是要表现出你不是在无脑用 AI，而是知道 AI 生成的东西哪里可能有坑、怎么 review、怎么改进。
1296

1297
- 本文已做格式统一与噪声清理，保留原始语义。
1298
- 15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑
1299
- # 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑
1300
- 11345. 现场实操：给定一个包含数据Schema的API文档，请使用AI工具在15分钟内生成符合RESTful规范的CRUD接口代码，并解释关键实现逻辑VIP中等大模型为方便拷贝至编辑器，以下文档以 Markdown 源码进行展示▼markdown复制代码# TodoList API 文档 (v1.0)## 基础信息-**Base URL**:`https://api.example.com/v1`-**数据格式**: JSON-认证方式: Bearer Token (需在Header中添加`Authorization: Bearer <token>`)
1301
- ---## 数据结构 Schema### Todo 对象| 字段名       | 类型    | 必填 | 描述                     |
1302
- |--------------|---------|------|--------------------------|
1303

1304
- 本文已做格式统一与噪声清理，保留原始语义。

Show moreShow less

秋招 AI应用开发 Agent 复习笔记

Wed, 10 Jun 2026 00:00:00 GMT

🎯 AI 应用开发 / Agent 方向 · 秋招复习笔记#

📅 整理时间：2026-06-02 📚 来源：基于 workspace 内 18 份面经资料整合 🎯 适用：AI 应用开发 / Agent 开发 / 大模型应用校招岗位

📖 总目录#

Agent 核心概念与架构
Agent 四种范式深度对比
RAG 检索增强生成
MCP 协议
Memory 记忆系统
Prompt 工程
Function Calling / Tool Use
Multi-Agent 多智能体架构
幻觉处理
上下文管理
工程化与可靠性设计
Agent 评测体系
项目面试话术
算法 / CS 基础高频点
各家大厂面经速览
贴心避坑指南

1. Agent 核心概念与架构#

1.1 什么是 Agent？#

Agent（智能体）是一种能够感知环境、做出决策并采取行动的系统。与普通 LLM 应用的核心区别：

维度	普通 LLM 应用	Agent
交互模式	输入→输出，单轮	多轮循环，自主规划
工具使用	无	调用外部 API、代码执行等
推理能力	单次推理	多步推理，反思纠错
目标驱动	被动响应	主动规划直到完成任务

1.2 Agent 四大核心组件（面试高频）#

1
┌─────────────────────────────────────┐
2
│              Agent                    │
3
│  ┌──────┐  ┌──────┐  ┌──────┐  ┌──┐ │
4
│  │规划   │  │记忆   │  │工具   │  │执行│ │
5
│  │Planning│ │Memory │  │Tools │  │Act│ │
6
│  └──────┘  └──────┘  └──────┘  └──┘ │
7
└─────────────────────────────────────┘

Planning（规划）：任务分解、反思、ReAct、CoT
Memory（记忆）：短期记忆（上下文窗口）、长期记忆（向量库）、工作记忆（执行状态）
Tools（工具）：Function Calling、MCP、自定义工具
Action（执行）：执行操作并观察结果

💡 面试回答模板：先讲这四要素，再结合你的项目具体展开。

1.3 Agent vs 大模型的本质区别#

大模型：静态参数推理，无记忆无工具
Agent：感知 → 规划 → 工具调用 → 执行 → 反馈 闭环
Agent 具备：自主性、反应性、目标导向、与环境的交互能力

2. Agent 四种范式深度对比#

⚠️ 高频难题：对比 React、Plan-and-Execute、Tool Use、Multi-Agent 四种范式 ⚠️ 最大误区：认为它们是线性进化关系（低级→高级）。实际上它们是不同维度的！

2.1 层次关系（面试必讲）#

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

👉 一个 Agent 可以同时用 ReAct + Function Calling，整个系统又是 Multi-Agent 架构。

2.2 各范式详解#

范式	层次	核心机制	优点	缺点	适用场景
Tool Use	基础能力层	模型自主决定是否调工具、调哪个、传什么参数	延迟低，架构简单	缺少全局规划，易偏离目标	简单调用（查天气、发邮件）
ReAct	推理框架层	Thought → Action → Observation 三段循环	可解释性强，有决策链路日志	每轮多一次 LLM 调用，延迟高	中等复杂度，需可观测性
Plan-and-Execute	流程控制层	先规划完整计划，再逐步执行，可重规划	全局视野，避免迷失	规划消耗资源，计划可能不准确	步骤多、结构清晰的任务（代码重构）
Multi-Agent	组织架构层	多 Agent 分工协作，消息通信	职责分离，上下文专注	通信开销，协调复杂度	角色天然分离的场景

2.3 技术选型优先级（面试加分回答）#

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

3. RAG 检索增强生成#

3.1 RAG 完整链路#

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

3.2 面试常考细节#

(1) Chunking 策略#

策略	说明	适用场景
固定大小滑动窗口	简单，实现容易	通用场景
语义分块	按段落/章节自然边界切分	结构化文档
递归分块	大块→小块逐级拆分	长文档

关键认知：chunking 决定了检索系统的上限。需要用评估集跑不同策略的效果对比。

(2) Embedding 模型#

OpenAI text-embedding-3-small/large
BGE 系列（BAAI）
M3E（国产）
Cohere Embed

(3) 向量数据库选型#

名称	特点
Milvus	开源高性能，企业级
Pinecone	云原生，管理简单
Weaviate	支持混合搜索
Chroma	轻量级，适合原型
FAISS	Facebook 开源，高效本地部署

(4) RAG 优化六大手段#

分块策略优化：按语义分块而不是固定长度
多路检索：向量检索 + 关键词(BM25)检索 + 混合检索
重排序(Rerank)：对候选结果二次排序，提升精度
上下文压缩：只保留和问题最相关的部分
查询改写：把用户问题改写成更适合检索的形式
反馈循环：根据用户满意度反向调整检索策略

(5) RAG vs 微调#

维度	RAG	Fine-tuning
成本	低	高（需要 GPU 训练）
更新	实时更新文档即可	需要重新训练
适用场景	知识问答、事实查询	特定风格/格式/行为对齐
对幻觉影响	减少（有参考依据）	可能加剧（死记硬背）

💡 面试高频追问：什么时候不应该上 RAG？答：当知识变化极快、或对延迟极度敏感、或模型本身已具备足够知识时。

(6) RAG 常见失败原因#

检索召回率不足（Top-K 太少或 chunking 不当）
检索到的上下文相关性低
注入的上下文干扰了模型判断
用户问题表述不规范

4. MCP 协议#

4.1 什么是 MCP#

MCP（Model Context Protocol）是 Anthropic 推出的模型上下文协议，用于标准化 LLM 与外部工具/数据源的交互方式。

4.2 MCP 工作方式#

1
LLM ←→ MCP Client ←→ MCP Server ←→ 外部工具/数据源
2
                  ↑              ↑
3
              JSON-RPC      Tool Schema 注册

4.3 MCP vs Function Calling#

对比维度	Function Calling	MCP
标准化程度	模型厂商各自定义	统一开放协议
工具发现	需预注册	动态发现
通信方式	JSON Schema 内嵌	独立 Server 进程
跨语言	取决于 SDK	Server 独立，语言无关
安全性	需自行隔离	Server 级隔离

4.4 MCP vs Skill（面试高频）#

对比	MCP	Skill
定位	标准化工具调用协议	封装好的任务级能力
粒度	单个工具/能力	一个完整功能的集合
复用性	跨平台通用	平台特定
关系	可作为 Skill 内部调用协议	可组合多个 MCP 工具

4.5 其他工具协议#

A2A（Agent-to-Agent）：Google 提出的 Agent 间通信协议
SSE（Server-Sent Events）：服务端推送，常用于流式输出
WebSocket：全双工通信，用于实时交互

5. Memory 记忆系统#

5.1 三层记忆结构（面试必答）#

层级	说明	存储方式	典型实现
短期记忆	当前对话上下文	滑动窗口 / 摘要压缩	Context Window
工作记忆	当前任务中间状态	进程内存	当前子目标、已收集证据
长期记忆	跨会话持久化信息	向量数据库 / KV存储	用户偏好、历史交互

5.2 记忆设计核心问题#

写入时机：不是所有信息都值得存 → 需要重要性打分+去重
检索方式：相关性和时效性要兼顾 → 时间衰减权重
遗忘策略：记忆库越来越大 → 检索精度下降 → 需要定期整理

5.3 长期记忆的生成与检索#

1
触发条件（任务完成/用户明确指示/重要信息出现）
2
  → 调用 LLM 对当前会话做摘要/结构化提取
3
  → 向量化存储到记忆库
4
  → 下次需要时通过语义检索召回
5
  → 动态注入上下文

💡 面试追问点：agent.md vs memory.md vs skills.md 的职责区分？

agent.md：定义 Agent 的行为规则、系统 prompt

memory.md：存储跨会话的长期记忆

skills.md：注册可复用的能力模块

6. Prompt 工程#

6.1 常见 Prompt 技术#

技术	说明	面试要点
Zero-shot	直接提问，无示例	基础
Few-shot	给几个输入输出示例	要能说清楚选 few shot 的原则
Chain-of-Thought (CoT)	引导模型逐步推理	适合数学/逻辑问题
ReAct	推理+行动交替	Agent 核心
Self-consistency	多次采样选最一致的答案	提升准确率

6.2 结构化 Prompt 设计原则#

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

6.3 优化 Prompt 的常见手段#

所有 Prompt 修改要版本化管理
关键指令放前面（模型更关注开头和结尾）
用分隔符明确区分不同信息块
显式注入约束减少模型”猜”的概率

7. Function Calling / Tool Use#

7.1 完整链路#

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

⚠️ 很多初学者只关注”模型怎么输出 function call”，忽略了前后两端的工程细节。

7.2 工具设计原则#

工具粒度：太大（模型难以理解） vs 太小（增加调用次数）
Schema 设计：description 对完成率影响很大
工具装载：不要一次性加载所有工具，按需选择
并发处理：独立工具可并行调用

7.3 工具 Schema 示例#

1
{
2
  "name": "search_document",
3
  "description": "搜索知识库中的文档，返回相关片段",
4
  "parameters": {
5
    "type": "object",
6
    "properties": {
7
      "query": {"type": "string", "description": "搜索关键词"},
8
      "top_k": {"type": "integer", "description": "返回结果数量"}
9
    },
10
    "required": ["query"]
11
  }
12
}

8. Multi-Agent 多智能体架构#

8.1 为什么用 Multi-Agent（面试话术）#

职责分离：不同 Agent 专注不同任务，代码结构清晰
能力扩展：独立扩展子 Agent，不影响整体
上下文精简：每个 Agent 只需关注自己的上下文窗口
协作效率：主 Agent 分解调度，子 Agent 并行执行

8.2 三种通信模式#

模式	说明	适用场景
Orchestrator（编排器）	主 Agent 拆任务、分配、汇总	简单分解任务
Peer-to-Peer（对等）	Agent 间平等协商	需要多方讨论
Hierarchical（层级）	上级管理下级	复杂组织结构

8.3 主Agent与子Agent通信#

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

9. 幻觉处理#

9.1 幻觉产生原因#

模型训练数据的偏差和不完整
上下文约束不足，模型自由发挥
检索到的信息相关性不足或错误

9.2 多层幻觉防御策略#

1
第一层：Prompt 约束
2
  → 要求模型引用来源、设置 temperature=0、指令约束
3

4
第二层：工具/函数调用
5
  → 用精确计算替代模型猜测（如计算器、查询数据库）
6

7
第三层：RAG 召回
8
  → 提供参考文档，减少依赖模型内部知识
9

10
第四层：后处理验证
11
  → 对输出做静态检查、格式校验、事实核查
12

13
第五层：微调对齐
14
  → 特定场景下用微调纠正模型行为

10. 上下文管理#

10.1 上下文压缩#

触发时机：

当前上下文长度接近模型上限（如 80%）
多轮对话中历史信息冗余

压缩方法：

方法	说明
摘要压缩	用模型生成历史摘要，保留核心信息
关键信息提取	抽取实体、动作、意图，丢弃次要描述
滑动窗口	只保留最近 N 轮对话

10.2 上下文结构组织#

优先级策略（从高到低）：

1
1. 系统规则 / 约束
2
2. 当前轮用户明确输入
3
3. 外部工具返回结果 / 知识库证据
4
4. 用户历史偏好（soft hint，不可覆盖当前事实）

10.3 会话压缩面试参考#

阿里淘天面试官追问：会话压缩怎么做的？
参考回答：当上下文窗口接近限制时，触发摘要压缩。先用模型对当前上下文生成摘要，保留系统指令、关键决策、已收集的重要信息，丢弃中间重复的推理过程和低价值日志。摘要完成后替换原始上下文，节省 token 空间。同时记录摘要的历史版本，必要时可回溯。

11. 工程化与可靠性设计#

11.1 异常处理三层策略#

层级	策略	说明
第一层	重试	指数退避重试，限制最大次数
第二层	降级	主工具失败换备用工具/简化路径
第三层	上报	处理不了交给人类介入

11.2 鲁棒性设计要点#

1
输入校验 → 意图识别 → 敏感词过滤 → 上下文截断 → 错误兜底
2
                          ↓
3
                  二次校验与格式解析

关键原则：

先校验用户输入，再决定是否调用模型
对关键输出做二次校验
不要为了”好看”，是为了系统不会因为一次异常直接崩掉

11.3 性能优化（面试要能展开）#

维度	具体措施
模型推理	流式输出(SSE)，减少感知延迟
工具调用	并行调用独立工具，连接池复用
网络传输	缓存(Semantic Cache)，减少重复请求
上下文组装	只注入必要上下文
预计算	确定性中间结果提前算好存储
熔断机制	工具连续失败超阈值时自动熔断

11.4 Token 消耗优化#

上下文压缩（摘要替换原始历史）
缓存（常用技能、知识不重复加载）
批处理（合并小请求）
模型选择（简单任务用轻量模型）

11.5 可审计 Agent 设计#

审计目标：能追责、能定因、能复现

需记录的信息：

用户输入
系统 prompt 版本
工具候选集 + 最终选择
调用参数 + 工具返回结果
状态变迁
模型输出 + 最终结果
扩展：模型版本、知识库版本、trace_id

12. Agent 评测体系#

12.1 四层评测体系（面试杀手锏）#

层级	内容	作用
第一层：保底	确保系统每次改动后仍能稳定运行	防止”改坏”
第二层：Benchmark	固定题目，用通过率、耗时、失败原因量化	避免”凭感觉”
第三层：过程记录	记录运行过程以便复盘	不只看到最终结果
第四层：回归	将真实翻车 case 放回评测集	贴近真实场景

12.2 Agent 评估维度#

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

12.3 评估方式#

离线评估：benchmark 跑回归测试
在线评估：真实用户留存、反馈、复用率
LLM-as-Judge：用 GPT-4 或其他模型评分

13. 项目面试话术#

13.1 项目介绍的”四步公式”#

1
业务痛点 → 初版方案 → 踩坑迭代 → 量化收益

错误示范：“我用了一套多 Agent 的系统，用了 RAG、Prompt 优化……” 正确示范：“我在 XX 场景下遇到了 XX 问题（业务场景），一开始尝试了 XX 方案（初版），但发现了 XX 问题（踩坑），于是改成了 XX，最终 XX 指标提升了 XX%（收益）。“

13.2 面试官最怕的 5 个追问（校招生专供）#

“这个设计你是怎么考虑的？有没有考虑过其他方案？” → 展示技术选型思考，说清楚为什么选 A 不选 B
“遇到过什么问题？怎么解决的？” → 展示真实踩坑经验，这是区分”做过”和”看过”的关键
“如果 XX 情况发生，系统会怎么样？” → 展示对边界情况的思考
“有量化的效果吗？” → 必须有指标，不能用”感觉”回答
“为什么这么设计？Trade-off 是什么？” → 展示架构权衡能力

13.3 项目包装要点#

不要说自己项目是”网上找的”，可以说”参考了 xx 开源方案，结合实际业务做了 xx 改进”
每个功能点都要能说出”为什么”，不只是”做了什么”
准备 1-2 个深度模块展开讲，其他一笔带过
准备完整的叙事：场景 → 问题 → 方案 → 迭代 → 收益

13.4 Skill 机制面试回答#

问题：skill 是怎么运作的？ 当用户提问触发条件时，系统从 skill 库匹配最合适的 skill，将其内容（自然语言描述 + JSON Schema）注入 Prompt 上下文，交由大模型处理。

问题：内置 skill 和业务自定义 skill 冲突了怎么办？

命名空间隔离（不同前缀/目录）
优先级机制（按规则选择）
冲突检测告警

问题：太长或不当的 skill 会导致什么？

上下文溢出，关键指令被截断
性能下降，Token 消耗增加
噪音干扰，降低执行准确性

14. 算法 / CS 基础高频点#

14.1 必刷算法#

高频题：合并两个有序数组、字符串相加、单例模式
每日必做：LeetCode Hot 100 + 剑指 Offer
Tips：刷过的题面试时假装思考一下再写

14.2 Java 高频八股#

模块	重点	面试要求
线程池	核心参数、拒绝策略、工作原理	✅ 能讲清配置，能设计
HashMap	底层结构、红黑树转换阈值(8)、扩容	✅ 原理+并发安全
JVM	类加载机制(三大步骤)、垃圾回收算法、内存分布	✅ 经典必考
并发	synchronized 原理、ReentrantLock、CAS、AQS	✅ 死锁要能写出来
MySQL	undo log/redo log/binlog + 两阶段提交	✅ 经典组合
单例	双检锁 + volatile	✅ 手写级

14.3 Python 相关#

多进程、多线程、协程的区别
Python vs JS 的区别

14.4 网络基础#

HTTP 1.0 / 2.0 / 3.0 区别
前后端分离概念
SSE / WebSocket

14.5 LLM / 算法基础（非训练岗也要知道）#

Transformer 流程
注意力机制
位置编码
过拟合 / 梯度消失
模型并行 / 数据并行

15. 各家大厂面经速览#

字节跳动（一面）#

题号	问题	核心考点
1	为什么要自己搞 code agent？挑战？	项目动机+深度
2	同一个模型不同 context 长度下的差异？	上下文工程
3	怎么减少 Agent 幻觉？	多层防御体系
4	Prompt 怎么构建的？	模块化+版本管理
5	Memory 机制怎么做？	短/长期记忆
6	任务恢复怎么做？	状态快照+恢复
7	怎么评测和验证优化效果？	四层评测体系

阿里淘天（一面）#

题号	问题	核心考点
1	会话压缩怎么做？	上下文管理
2	长期记忆写入时机？	记忆系统设计
3	上下文结构 / 长度约束？	Prompt 工程+Token控制
4	agent.md vs memory.md 职责区分？	架构理解
5	工具和 skill 位置互换的后果？	架构权衡
6	怎么评测 Agent 回答质量？	评估体系
7	HashMap + 线程池 + 并发	Java 基础

腾讯（一面→二面）#

一面：概念型题（什么是 Agent、RAG、Prompt Engineering）
二面：系统设计题（Planner 设计、上下文优先级、异常处理、可审计 Agent）
二面和一面最大区别：一面问”会不会”，二面问”为什么不这么做、不这么做会出什么问题”

滴滴 AI 全栈（一面）#

MCP 深度题（运作方式、协议对比、并发处理）
AI coding tools 了解程度
MCP vs Skill 区别
前端基础+后端基础都会问
智能体三要素

16. 贴心避坑指南#

❌ 常见翻车现场#

1. 项目被问倒

项目是网上找的 → 被面试官看轻
项目挑战答不上来 → 面试官觉得你没做过
没有量化指标 → 话术再好也白搭

2. 八股只会背

背了线程池参数 → 追问”怎么设计一个” → 露馅
背了 RAG 流程 → 追问”chunking 怎么选” → 卡住

3. 忽略工程细节

会说”流式输出” → 说不清缓存、超时、降级
会说”做了评测” → 说不清评测维度

✅ 制胜关键点#

实习经历是最大加分项 → 你现在就在做 AI 应用+Agent，珍惜每个遇到的真实问题
每天实习时记录踩坑细节 → 面试时这就是你的”真实感”
项目表达用”先讲场景，再讲方案”
准备一个”原理→配置→常见问题→排查方法”四件套
每个设计决策都要能说出 trade-off

👑 最终面试官想看到的#

企业现在更看重的，不是你会不会调 API，而是：

出了问题你能不能定位

系统异常你能不能兜住

方案落地后你能不能让它稳定跑起来

💪 退出挑战杯省下的时间和心力，现在全部可以投入到秋招准备中。方向正是你感兴趣的 AI Agent，这就是你说的”想做的有意义的事”。加油！

秋招AI面经问题all

Wed, 10 Jun 2026 00:00:00 GMT

秋招以来的AI面经问题 All#

来源：小红书 @玖原文链接：http://xhslink.com/o/4THd9NZseQI 发布时间：2026-01-30 标签：面试、面经、校招、秋招、互联网大厂、AI 收藏 1633 · 点赞 815 · 评论 37

面经问题汇总（共43题）#

为什么做 Agent 项目？
了解过市面上有哪些智能体 Agent 吗
讲下 Agent 项目
Agent 项目开发的框架
介绍一些 AI 大模型
RAG 系统流程
MCP 和 Function Calling
如何写好的 Prompt
多轮对话的实现方案
Agent 项目背景
LLM 产生幻觉的原因及解决方案
MCP 协议的核心内容
推理模式的差异化设计
RAG 检索优化策略
特定推理模型不支持 MCP 的技术原因
Agent 推理模式
跨模块错误追踪的 Agent 知识库构建方案
多 Agent 执行策略的智能选择和切换机制设计
简历关键词提取的技术实现
RAG 评估方案
SSE 的局限性
举例复杂任务下执行流程
MCP 通信方式
项目中 AI 贡献的代码占比
Prompt 是如何优化的
Agent 框架有哪些，比较优劣
Multi Agent 方案
上下文工程
任务规划
模型选型
前后端怎么通信的
介绍一下 Transformer
做 Agent 是怎么学习的
RAG 检索是怎么做的
ChatGPT 等 LLM 的原理
Function Calling 流程
RAG 怎么做
Embedding 模型怎么选
Prompt 写法
如何优化大模型幻觉
MCP 是什么，为什么要学
向量数据库和传统数据库区别
Agent 长短期记忆怎么做的

分类统计#

类别	题数
Agent 基础与项目	10
RAG 检索增强生成	6
MCP 协议	5
Prompt 工程	4
大模型原理	4
Multi-Agent	3
Function Calling	2
其他工程实践	9

腾讯大模型应用开发二面

Wed, 10 Jun 2026 00:00:00 GMT

腾讯大模型应用开发二面#

来源：小红书 @逸原文链接：http://xhslink.com/o/5vDCA2JigSO 发布时间：2026-04-12 标签：面试、面经、AI、Agent、实习

Q1：如果让你设计一个 Agent 的规划器，怎么避免它每一步都重新规划，导致路径震荡？#

规划器不能每拿到一个 observation 就整体重算，不然很容易出现前一步刚决定检索，后一步又改成思考，再下一步又回去检索，整个执行路径会来回抖动。

更稳的做法是把规划分成**“全局计划”和”局部调整”**两层。全局计划只定义阶段目标，比如信息收集、证据校验、结果生成；局部调整只允许在当前阶段内微调具体动作。

另外要给 planner 一个明确的状态表示，比如当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束，模型会把每次新 observation 当成全新任务来理解。

线上一般还会加**“重规划阈值”**，只有在关键前提失效、连续失败或者用户目标变化时才允许重规划，这样路径会稳定很多。

Q2：如果一个 Agent 需要同时查知识库、调外部 API、再结合用户历史偏好回答，你怎么处理这三类上下文的优先级？#

这三类信息不能混着塞，要先定义优先级。通常系统规则最高，接下来是当前轮用户明确输入，再往下是外部工具返回和知识库证据，用户历史偏好通常最低。因为偏好只能影响表达方式或默认选择，不能覆盖当前轮事实。

比如用户历史里一直偏好 Python，但这轮明确说”用 Java 给我写”，那当前轮约束一定优先。

这几类上下文不能一股脑全塞进 prompt，要有分层拼接策略，每层标注来源和可信度。工具返回的结果也要做可信度排序，因为有些工具返回的是参考值，有些是精确计算。拼的时候系统约束放最前面，用户输入紧随其后，工具和知识库结果按相关性排，偏好信息放最后，作为 soft hint。

Q3：如何评估一个 Agent 的好坏？#

不能只看最终答案对不对，还要看过程。通常会从这几个维度评估：

任务完成率：有没有达到目标
步骤效率：花了多少步、有没有走弯路
工具调用准确率：选对工具、参数填对、返回结果正确使用
幻觉率：有没有编造不存在的信息或工具
用户满意度：用户愿不愿意继续用

评估方式分离线和在线两种：

离线：用 benchmark 数据集跑回归测试
在线：看真实用户留存、反馈和复用率

很多团队只关注离线指标，但上线后真正有用的是在线指标，因为离线数据很难覆盖边界情况和长尾场景。线上还要看异常恢复率（出了错能不能自己修回来）和人类介入率（有多少任务需要人接管），这两个指标直接反映了 Agent 的工程成熟度。

Q4：Agent 里的 Memory 机制怎么设计？#

Agent 的记忆分三层：

层级	说明	存储方式
短期记忆	当前对话的上下文窗口	滑动窗口或摘要压缩
长期记忆	跨会话持久化信息（用户偏好、历史交互、知识）	向量数据库或 KV 存储
工作记忆	当前任务执行中的中间状态（已收集证据、已尝试方案、当前子目标）	进程内存

设计时要考虑三个核心问题：

写入时机：不是所有信息都值得存，要做重要性打分和去重
检索方式：相关性和时效性要兼顾
遗忘策略：不然记忆库越来越大、越来越杂，检索精度反而下降

Q5：Function Calling 和 Tool Use 有什么区别？#

Function Calling 是模型侧的能力：模型在生成过程中决定要调用哪个函数、传什么参数，然后把调用意图以结构化格式输出。

Tool Use 是更广义的概念，包括 Function Calling 以及外部工具的注册、发现、调度、执行和结果回传。在实际工程里，Function Calling 只是 Tool Use 链路中的一环。

完整链路还包括：

工具注册：告诉模型有哪些工具、每个工具的 schema
工具选择：有几十个工具时怎么快速筛选候选
参数校验：模型填的参数可能不合法
执行隔离：工具执行可能出错、超时、返回异常
结果处理：工具返回的原始数据怎么注入回上下文

很多初学者只关注模型怎么输出 function call，忽略了前后两端的工程细节。

Q6：怎么处理 Agent 执行过程中的异常和错误？#

常见异常分四类：工具调用失败（网络超时、服务不可用、参数错误）、模型输出异常（幻觉、格式错误、输出截断）、状态不一致（上下文过长、记忆冲突）、业务逻辑异常（用户目标变更、权限不足）。

处理策略分三层：

层级	策略	说明
第一层	重试	对临时性错误用指数退避重试，限制最大重试次数
第二层	降级	主工具失败时换备用工具或切换更简单的执行路径
第三层	上报	自己处理不了的交给人类介入或切换到人工客服

每层都要记录详细的错误日志和上下文快照，方便后续排查。线上 Agent 一定要有熔断机制，当某个工具连续失败率超过阈值时自动熔断，避免无效调用浪费资源和时间。

Q7：你怎么理解 Agent 的 Planning 能力？#

Planning 不是简单让模型列个 to-do list，而是让模型根据当前状态和目标动态决定下一步做什么。

常见 Planning 范式：

范式	特点	适用场景
ReAct	交替推理和执行，每步根据上一步结果决定下一步	简单任务
Plan-and-Execute	先生成完整计划再逐步执行，偏离时重新规划	复杂任务
Tree of Thought	探索多条分支路径，选最优的继续	需要对比多种方案

实际工程里通常混合使用。Planning 的难点不在于生成计划，而在于：

如何判断计划是否偏离
何时需要重新规划
如何避免重复失败的路径

Q8：Multi-Agent 系统怎么设计？#

核心是分工、协调和仲裁：

分工：明确每个 Agent 的职责边界和能力范围，避免职责重叠
协调：统一的消息协议和状态同步机制
仲裁：多个 Agent 给出不同结果时，由谁决定最终输出

常见架构模式：

模式	说明	适用场景
Orchestrator	主 Agent 拆解任务、分配子 Agent、汇总结果	简单分解任务
Peer-to-Peer	Agent 之间平等协商	需要多方讨论
Hierarchical	层级管理，上级管理下级	复杂组织结构

Q9：如何优化 Agent 的响应延迟？#

延迟优化要分阶段看：模型推理、工具调用、网络传输、上下文组装。

阶段	优化手段
模型推理	流式输出，减少感知延迟
工具调用	并行调用多个独立工具
网络传输	缓存减少重复请求，连接池复用
上下文组装	只注入必要上下文，避免无关信息
预计算	确定性中间结果提前算好存起来

整体思路：能并行的并行、能缓存的缓存、能裁剪的裁剪、能预计算的预计算。

Q10：RAG 系统常见的问题和优化方案？#

核心问题三类：检索不准、上下文不够、生成质量差。

优化方案：

分块策略优化：按语义分块而不是固定长度
多路检索：向量检索 + 关键词检索 + 混合检索
重排序：用 reranker 对候选结果二次排序
上下文压缩：只保留和问题最相关的部分
查询改写：把用户问题改写成更适合检索的形式
反馈循环：根据用户满意度反向调整检索策略

Q11：如果让你做一个”可审计”的 Agent，你会保留哪些信息？#

可审计不是简单把聊天记录存下来，而是要能还原**“它为什么这样做”**。

至少要保留：

用户输入
系统 prompt 版本
工具候选集
最终工具选择
调用参数、工具返回
状态变迁
模型输出和最终结果

更完整的还要带上：模型版本、知识库版本、检索到的文档 ID、rerank 结果、trace_id。

线上出了问题，才能准确回放是 prompt 变了、知识库变了、模型变了，还是工具变了。真正的审计目标不是”存档”，而是**“能追责、能定因、能复现”**。

Q12：为什么很多 Agent Demo 很惊艳，但一上线就不稳定？#

因为 Demo 是在理想输入、有限工具、单次任务和短上下文下演示的，模型只要看起来会做事就行。但线上环境完全不一样——输入脏、任务长、工具多、状态复杂、异常频繁，还要考虑权限、安全、性能和成本。

Demo 能跑通，只能说明**“这个方向有可能”；上线稳定，说明的是你把模型的不确定性关进了工程笼子里**。

真正难的是做治理，不是做演示。很多团队一开始总怪模型不够强，后来才发现大量问题其实来自：状态管理、工具设计、上下文污染和缺少回放能力。

Q13：你觉得二面和一面在 AI Agent 方向上最大的区别是什么？#

一面很多时候还会看你知不知道概念，比如 RAG、Tool Calling、Memory、Multi-Agent 这些名词你能不能说清。

二面通常就不满足于名词解释了，更想知道你能不能把这些东西真正落到系统里。会追着问边界条件、失败案例、线上治理和设计取舍。不是问你”会不会”，而是问你**“为什么不这么做，不这么做会出什么问题”**。

如果你答的时候一直停留在定义层面，二面一般很容易被看出来。

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传整理

Wed, 10 Jun 2026 00:00:00 GMT

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_#

问题#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_

标准回答#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2450面试问答Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。先说工具定义。每个工具本质上就是一段 JSON Schema（一种描述数据结构的标准格式），里面包含工具的名字、一段自然语言描述、以及参数的类型约束。LLM 不会直接执行任何代码，它只认这段 Schema 文本。你在系统侧注册好工具，然后把这些 Schema 塞进 system prompt 或者 tools 字段传给 LLM：▼json复制代码{“name”:“get_weather”,“description”:“查询指定城市的当前天气”,“parameters”:{“type”:“object”,“properties”:{“city”:{“type”:“string”,“description”:“城市名称”}},“required”:[“city”]}}然后是LLM 决策调用。LLM 收到用户消息和工具列表后，如果判断当前问题得调用工具，它不会直接回答用户，而是返回一个特殊的tool_use消息，里面带着工具名和填好的参数 JSON。备注：不同厂商命名不同，OpenAI 用 tool_calls，Anthropic 用 tool_use，本文以 Anthropic 命名为例。注意，LLM 只是”说”它想调什么工具、传什么参数，它自己压根不会去执行。这跟你在聊天里说”帮我查一下天气”一样，说的人不会真的去查，执行的是系统侧。系统侧拿到 tool_use 消息后，解析出工具名，找到本地注册的对应函数，把参数传进去跑。执行完拿到结果，包装成 tool_result 消息追加到对话历史里，再整个发回给 LLM。LLM 看到 tool_result 后有两种选择：如果信息够了就直接生成最终回答如果还需要更多信息，它会再发一个 tool_use，形成一个循环，直到它认为可以回复用户为止。整个链路：用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use 含工具名和参数 → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

扩展知识#

从 Function Calling 到 Tool Calling 的演进OpenAI 最早在 2023 年 6 月推出的叫Function Calling，当时一次只能调一个函数。到了 2023 年 11 月，升级成了 Tool Calling，最大的变化是支持 parallel tool calls，LLM 一次可以返回多个 tool_use，系统可以并行执行完再统一回传结果。举个场景：用户问”北京和上海今天天气怎么样”，用 Function Calling 的话 LLM 得先调一次 get_weather(“北京”)，等结果回来再调 get_weather(“上海”)，两轮网络往返。换成 Tool Calling，LLM 直接返回两个 tool_use，系统并发执行，一轮就搞定了。Anthropic 的 Claude、Google 的 Gemini 也都支持 Tool Calling，机制基本一样，但在 Schema 处理上有差异。比如 Gemini 不支持 patternProperties 和 additionalProperties 这些关键字，xAI 不支持 minLength、maxLength 约束，OpenAI 要求参数顶层必须是 type: “object”。实际工程里通常需要一层 Schema 归一化来抹平这些差异。工具结果的上下文管理工具返回的数据量可能非常大。一次代码搜索可能返回 50KB 的内容，直接塞进上下文会快速吃掉 token 配额。生产级系统一般会做截断处理，常见的策略是 head + tail 保留，取开头和结尾各一部分，中间用省略标记替代，同时设置单条结果的上限，比如一般会设置单条结果占上下文窗口比例的上限（如 20%-30%）以及字符数硬上限。安全和权限控制工具调用是 Agent 系统里最容易出安全问题的环节。LLM 可能被 prompt injection 诱导去调用不该调的工具，比如删除文件、发送邮件。所以生产环境至少要做三件事：1）工具白名单，只暴露当前场景必需的工具。

2）参数校验，不能完全信任 LLM 填的参数，服务端必须做 Schema 验证和业务规则校验。

3）敏感操作加人工确认，像 LangChain 的 HumanApprovalCallbackHandler 就是在执行前弹一个确认。错误处理和重试工具执行失败是常态，网络超时、API 限流、参数格式错误都可能发生。好的做法是把错误信息也包装成 tool_result 返回给 LLM，让它自己决定怎么处理。大多数模型看到错误后会尝试修改参数重新调用，或者换一个工具，或者直接告诉用户”这个信息暂时查不到”。但要注意设置最大重试次数，不然 LLM 可能陷入死循环不停地调同一个工具。一般 3-5 次就够了，超了就强制返回。

面试官追问#

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？回答：两层防线。第一层是在系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型看到具体的报错信息后会自己修正参数重新调用。第二层是设置重试上限，一般 3 次，避免来回纠错死循环。- 提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？
回答：各工具的执行结果是独立回传的，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，这跟 Promise.allSettled 的思路一样。- 提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？
回答：RAG 是”提前检索、一次性注入”，把相关文档片段塞进 prompt 就完事了，适合知识查询类的场景。Tool Calling 是”按需执行、多轮交互”，LLM 在推理过程中动态决定要不要调、调哪个，适合需要实时数据、需要执行副作用的场景，比如查数据库、发请求、操作文件系统。简单说，RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。- 提问：怎么让 LLM 更准确地选择正确的工具？
回答：工具的 description 写得好不好直接决定调用准确率。description 要写清楚这个工具干什么、什么场景该用、什么场景不该用。参数的 description 也一样重要，别偷懒写个”id”就完了，要写明白”用户的唯一标识符，必须是数字格式”。另外工具数量不能太多，超过 15-20 个的时候 LLM 选择准确率会明显下降，这时候要么分场景加载不同的工具集，要么做一层路由先判断意图再加载对应工具。作者：Yes面试鸭官方工具定义：工具本质是一段 JSON Schema，包含工具名字、一段自然语言描述、参数的类型约束。

LLM角色调用：受到用户消息和工具列表后，判断当前问题得调用工具，返回一个特殊的tool_use 消息，里面带着工具名和填好的参数 JSON展开新页面打开2026-03-14 11:4200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

从 Function Calling 到 Tool Calling 的演进工具结果的上下文管理安全和权限控制错误处理和重试

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？提问：怎么让 LLM 更准确地选择正确的工具？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:2813221. 请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2450面试问答Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。先说工具定义。每个工具本质上就是一段 JSON Schema（一种描述数据结构的标准格式），里面包含工具的名字、一段自然语言描述、以及参数的类型约束。LLM 不会直接执行任何代码，它只认这段 Schema 文本。你在系统侧注册好工具，然后把这些 Schema 塞进 system prompt 或者 tools 字段传给 LLM：▼json复制代码{“name”:“get_weather”,“description”:“查询指定城市的当前天气”,“parameters”:{“type”:“object”,“properties”:{“city”:{“type”:“string”,“description”:“城市名称”}},“required”:[“city”]}}然后是LLM 决策调用。LLM 收到用户消息和工具列表后，如果判断当前问题得调用工具，它不会直接回答用户，而是返回一个特殊的tool_use消息，里面带着工具名和填好的参数 JSON。备注：不同厂商命名不同，OpenAI 用 tool_calls，Anthropic 用 tool_use，本文以 Anthropic 命名为例。注意，LLM 只是”说”它想调什么工具、传什么参数，它自己压根不会去执行。这跟你在聊天里说”帮我查一下天气”一样，说的人不会真的去查，执行的是系统侧。系统侧拿到 tool_use 消息后，解析出工具名，找到本地注册的对应函数，把参数传进去跑。执行完拿到结果，包装成 tool_result 消息追加到对话历史里，再整个发回给 LLM。LLM 看到 tool_result 后有两种选择：如果信息够了就直接生成最终回答如果还需要更多信息，它会再发一个 tool_use，形成一个循环，直到它认为可以回复用户为止。整个链路：用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use 含工具名和参数 → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

2）参数校验，不能完全信任 LLM 填的参数，服务端必须做 Schema 验证和业务规则校验。

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？回答：两层防线。第一层是在系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型看到具体的报错信息后会自己修正参数重新调用。第二层是设置重试上限，一般 3 次，避免来回纠错死循环。- 提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？
回答：各工具的执行结果是独立回传的，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，这跟 Promise.allSettled 的思路一样。- 提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？
回答：RAG 是”提前检索、一次性注入”，把相关文档片段塞进 prompt 就完事了，适合知识查询类的场景。Tool Calling 是”按需执行、多轮交互”，LLM 在推理过程中动态决定要不要调、调哪个，适合需要实时数据、需要执行副作用的场景，比如查数据库、发请求、操作文件系统。简单说，RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。- 提问：怎么让 LLM 更准确地选择正确的工具？
回答：工具的 description 写得好不好直接决定调用准确率。description 要写清楚这个工具干什么、什么场景该用、什么场景不该用。参数的 description 也一样重要，别偷懒写个”id”就完了，要写明白”用户的唯一标识符，必须是数字格式”。另外工具数量不能太多，超过 15-20 个的时候 LLM 选择准确率会明显下降，这时候要么分场景加载不同的工具集，要么做一层路由先判断意图再加载对应工具。作者：Yes面试鸭官方工具定义：工具本质是一段 JSON Schema，包含工具名字、一段自然语言描述、参数的类型约束。

alt

代码代码代码块

编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表

从 Function Calling 到 Tool Calling 的演进工具结果的上下文管理安全和权限控制错误处理和重试

来源: 请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_.mhtml

关键点#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?#
问题#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?

NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2450面试问答Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。
打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。
Tool Calling 就是这个”下命令再拿报告”的标准化流程。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_

问题#

2）参数校验，不能完全信任 LLM 填的参数，服务端必须做 Schema 验证和业务规则校验。

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？回答：两层防线。第一层是在系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型看到具体的报错信息后会自己修正参数重新调用。第二层是设置重试上限，一般 3 次，避免来回纠错死循环。- 提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？
回答：各工具的执行结果是独立回传的，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，这跟 Promise.allSettled 的思路一样。- 提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？
回答：RAG 是”提前检索、一次性注入”，把相关文档片段塞进 prompt 就完事了，适合知识查询类的场景。Tool Calling 是”按需执行、多轮交互”，LLM 在推理过程中动态决定要不要调、调哪个，适合需要实时数据、需要执行副作用的场景，比如查数据库、发请求、操作文件系统。简单说，RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。- 提问：怎么让 LLM 更准确地选择正确的工具？
回答：工具的 description 写得好不好直接决定调用准确率。description 要写清楚这个工具干什么、什么场景该用、什么场景不该用。参数的 description 也一样重要，别偷懒写个”id”就完了，要写明白”用户的唯一标识符，必须是数字格式”。另外工具数量不能太多，超过 15-20 个的时候 LLM 选择准确率会明显下降，这时候要么分场景加载不同的工具集，要么做一层路由先判断意图再加载对应工具。作者：Yes面试鸭官方工具定义：工具本质是一段 JSON Schema，包含工具名字、一段自然语言描述、参数的类型约束。
LLM角色调用：受到用户消息和工具列表后，判断当前问题得调用工具，返回一个特殊的tool_use 消息，里面带着工具名和填好的参数 JSON展开新页面打开2026-03-14 11:4200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

从 Function Calling 到 Tool Calling 的演进工具结果的上下文管理安全和权限控制错误处理和重试

2）参数校验，不能完全信任 LLM 填的参数，服务端必须做 Schema 验证和业务规则校验。

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？回答：两层防线。第一层是在系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型看到具体的报错信息后会自己修正参数重新调用。第二层是设置重试上限，一般 3 次，避免来回纠错死循环。- 提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？
回答：各工具的执行结果是独立回传的，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，这跟 Promise.allSettled 的思路一样。- 提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？
回答：RAG 是”提前检索、一次性注入”，把相关文档片段塞进 prompt 就完事了，适合知识查询类的场景。Tool Calling 是”按需执行、多轮交互”，LLM 在推理过程中动态决定要不要调、调哪个，适合需要实时数据、需要执行副作用的场景，比如查数据库、发请求、操作文件系统。简单说，RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。- 提问：怎么让 LLM 更准确地选择正确的工具？
回答：工具的 description 写得好不好直接决定调用准确率。description 要写清楚这个工具干什么、什么场景该用、什么场景不该用。参数的 description 也一样重要，别偷懒写个”id”就完了，要写明白”用户的唯一标识符，必须是数字格式”。另外工具数量不能太多，超过 15-20 个的时候 LLM 选择准确率会明显下降，这时候要么分场景加载不同的工具集，要么做一层路由先判断意图再加载对应工具。作者：Yes面试鸭官方工具定义：工具本质是一段 JSON Schema，包含工具名字、一段自然语言描述、参数的类型约束。
LLM角色调用：受到用户消息和工具列表后，判断当前问题得调用工具，返回一个特殊的tool_use 消息，里面带着工具名和填好的参数 JSON展开新页面打开2026-03-14 11:4200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

从 Function Calling 到 Tool Calling 的演进工具结果的上下文管理安全和权限控制错误处理和重试

来源: 请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_.mhtml

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?#
- 问题#

请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?

本文已做格式统一与噪声清理，保留原始语义。
请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传_
请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?#
1. 请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2450面试问答Tool Calling 的核心链路就四步：定义工具 → LLM 决策 → 系统执行 → 结果回传。打个比方：LLM 就像一个只会动嘴的指挥官，它不能亲自去查数据库、读文件，但它可以”下命令”让外部系统去执行，然后看执行报告决定下一步。Tool Calling 就是这个”下命令再拿报告”的标准化流程。先说工具定义。每个工具本质上就是一段 JSON Schema（一种描述数据结构的标准格式），里面包含工具的名字、一段自然语言描述、以及参数的类型约束。LLM 不会直接执行任何代码，它只认这段 Schema 文本。你在系统侧注册好工具，然后把这些 Schema 塞进 system prompt 或者 tools 字段传给 LLM：▼json复制代码{“name”:“get_weather”,“description”:“查询指定城市的当前天气”,“parameters”:{“type”:“object”,“properties”:{“city”:{“type”:“string”,“description”:“城市名称”}},“required”:[“city”]}}然后是LLM 决策调用。LLM 收到用户消息和工具列表后，如果判断当前问题得调用工具，它不会直接回答用户，而是返回一个特殊的tool_use消息，里面带着工具名和填好的参数 JSON。备注：不同厂商命名不同，OpenAI 用 tool_calls，Anthropic 用 tool_use，本文以 Anthropic 命名为例。注意，LLM 只是”说”它想调什么工具、传什么参数，它自己压根不会去执行。这跟你在聊天里说”帮我查一下天气”一样，说的人不会真的去查，执行的是系统侧。系统侧拿到 tool_use 消息后，解析出工具名，找到本地注册的对应函数，把参数传进去跑。执行完拿到结果，包装成 tool_result 消息追加到对话历史里，再整个发回给 LLM。LLM 看到 tool_result 后有两种选择：如果信息够了就直接生成最终回答如果还需要更多信息，它会再发一个 tool_use，形成一个循环，直到它认为可以回复用户为止。整个链路：用户发消息 → LLM 分析消息和工具列表 → LLM 返回 tool_use 含工具名和参数 → 系统执行工具函数 → 系统构造 tool_result → 发回 LLM → LLM 决定继续调用或输出最终回复

2）参数校验，不能完全信任 LLM 填的参数，服务端必须做 Schema 验证和业务规则校验。

提问：如果 LLM 返回的工具参数格式不对，比如少了必填字段或者类型不匹配，你怎么处理？回答：两层防线。第一层是在系统侧用 JSON Schema 做参数校验，不合规直接拦住不执行，把校验错误信息包装成 tool_result 返回给 LLM，大多数模型看到具体的报错信息后会自己修正参数重新调用。第二层是设置重试上限，一般 3 次，避免来回纠错死循环。- 提问：parallel tool calls 并行执行多个工具的时候，如果其中一个失败了怎么办？
回答：各工具的执行结果是独立回传的，失败的那个单独返回错误信息，成功的正常返回结果。所有 tool_result 一起发回给 LLM，让它自己判断：可能只用成功的那几个结果就够了，也可能决定重试失败的那个。不需要全部成功才继续，这跟 Promise.allSettled 的思路一样。- 提问：Tool Calling 和 RAG 都是给 LLM 补充外部信息，它们的边界在哪？
回答：RAG 是”提前检索、一次性注入”，把相关文档片段塞进 prompt 就完事了，适合知识查询类的场景。Tool Calling 是”按需执行、多轮交互”，LLM 在推理过程中动态决定要不要调、调哪个，适合需要实时数据、需要执行副作用的场景，比如查数据库、发请求、操作文件系统。简单说，RAG 解决”LLM 不知道的事”，Tool Calling 解决”LLM 做不到的事”。- 提问：怎么让 LLM 更准确地选择正确的工具？
回答：工具的 description 写得好不好直接决定调用准确率。description 要写清楚这个工具干什么、什么场景该用、什么场景不该用。参数的 description 也一样重要，别偷懒写个”id”就完了，要写明白”用户的唯一标识符，必须是数字格式”。另外工具数量不能太多，超过 15-20 个的时候 LLM 选择准确率会明显下降，这时候要么分场景加载不同的工具集，要么做一层路由先判断意图再加载对应工具。作者：Yes面试鸭官方- 工具定义：工具本质是一段 JSON Schema，包含工具名字、一段自然语言描述、参数的类型约束。
LLM角色调用：受到用户消息和工具列表后，判断当前问题得调用工具，返回一个特殊的tool_use 消息，里面带着工具名和填好的参数 JSON展开新页面打开2026-03-14 11:4200回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
alt
代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

从 Function Calling 到 Tool Calling 的演进工具结果的上下文管理安全和权限控制错误处理和重试

本文已做格式统一与噪声清理，保留原始语义。

请解释大模型微调(Fine tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？整理

Wed, 10 Jun 2026 00:00:00 GMT

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？#

问题#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

标准回答#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。本质上是在通用知识的基础上”精雕细琢”，让模型在某个垂直领域表现得更专业。微调的核心原理是迁移学习。预训练模型已经在海量数据上学会了语言的通用规律，微调就是在这个基础上，用少量的领域数据让模型学会特定领域的表达方式和知识。打个比方，预训练模型像是读完了整个图书馆的通才，微调就是让它去医院实习三个月，变成一个懂医学的通才。什么时候需要微调而不是直接用基础模型？主要看这几种情况：1）专业领域应用。比如医疗诊断、法律咨询这类场景，GPT 对骨科、心内科的专业术语和诊疗逻辑掌握得不够深，直接拿来用容易出错。这时候用 10 万条专科病历数据做微调，准确率能从 60% 提到 90% 以上。

2）数据安全要求高的场景。金融机构、政府部门的内部数据不能传到 OpenAI 的服务器上，只能把 LLaMA、Qwen 这类开源模型拉下来，在自己的机房里微调部署。

3）特定任务需要稳定输出。像客服机器人、代码补全这类场景，用 Prompt 工程虽然也能跑，但输出格式不稳定，token 消耗大。微调一版专用模型，响应速度快、成本低，还不用每次都塞一堆 few-shot 示例。

扩展知识#

微调的底层原理预训练阶段，模型在 TB 级别的文本上做自回归训练，学会了”给定前文预测下一个词”的能力。这个过程会消耗几千张 A100 跑几个月，成本上千万美元。微调阶段的学习率通常比预训练低 1-2 个数量级，比如预训练用 1e-4，微调可能用 1e-5 或 2e-6。原因是预训练模型的参数已经在一个相对优秀的位置了，学习率太大会把这些好的权重带偏，造成灾难性遗忘，模型忘掉原来学会的通用能力。训练数据量上，全参数微调一般需要 1 万到 10 万条高质量样本，LoRA 这类参数高效方法可能几千条就能起效。数据格式通常是 instruction-input-output 三元组，或者直接是 QA 对。

主流微调方法对比#

目前业界常用的微调方法分两大类：全参数微调直接更新模型所有参数，效果最好但资源消耗也最大。一个 7B 参数的模型全参微调，至少需要 80GB 显存（A100 80G 或者 2 张 A100 40G），训练 1 万条数据大概跑 2-3 小时。参数高效微调只更新一小部分参数，其他参数冻结。代表方法有：LoRA 在原始权重矩阵旁边插入两个低秩矩阵 A 和 B，只训练这两个小矩阵。7B 模型用 LoRA 微调，显存需求降到 24GB 左右，一张 RTX 4090 就能跑，可训练参数量只有原来的 0.1%-1%。QLoRA 在 LoRA 基础上加了 4bit 量化，显存进一步压到 12GB 以下，消费级显卡也能微调大模型。Adapter 在 Transformer 层之间插入小型全连接模块，训练时只更新 Adapter 的参数。Prefix-tuning 在输入前面拼接可学习的虚拟 token，只训练这些前缀向量。| 方法 | 可训练参数占比 | 显存需求 |（7B模型）适用场景| 全参数微调 | 100% | 80GB+ |追求极致效果，资源充足| LoRA | 0.1%-1% | 24GB |资源有限，多任务切换| QLoRA | 0.1%-1% | 12GB |消费级显卡，个人开发者| Adapter | 1%-5% | 30GB |需要频繁切换任务

微调 vs Prompt 工程 vs RAG#

这三种方法都能让模型适配特定任务，但适用场景不同：Prompt 工程适合快速验证，不需要训练，改改提示词就能跑。缺点是每次推理都要塞一堆 few-shot 示例，token 消耗大，context window 有限，塞不下太多背景知识。RAG适合知识库场景，把问题扔给向量数据库检索相关文档，再喂给模型生成答案。好处是知识可以实时更新，不用重新训练。缺点是检索质量依赖 embedding 模型和切分策略，复杂推理能力还得靠模型本身。微调适合模型能力本身不够的情况，比如需要学会特定的推理模式、输出格式、领域术语。知识直接编码进参数里，推理时不需要额外的 context。实际项目中这三种方法经常组合使用。比如先微调一版领域模型，再用 RAG 补充实时知识，最后用 Prompt 控制输出格式。

实践中的坑#

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

2）验证集要足够有代表性。很多人只看训练 loss 下降就觉得微调成功了，结果拿去用发现效果很差。一定要留出 10%-20% 的数据做验证，而且验证集要覆盖实际使用的各种场景。

3）灾难性遗忘。微调过度模型会忘掉原来的通用能力，只会回答训练集里见过的问题。可以在微调数据里混入一部分通用数据，或者用 LoRA 这种方法，原始参数不动就不会遗忘。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

面试官追问#

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？提问：怎么判断一个任务应该用微调还是 RAG？提问：微调后模型效果变差了，怎么排查？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

微调的过拟合风险如何通过正则化缓解？上次浏览：2026-03-16 15:06:11请详细讨论微调时如何防止灾难性遗忘问题？在多模态微调（如图文生成）中，如何确保文本和图像数据的对齐质量？上次浏览：2026-03-16 15:02:13请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？上次浏览：2026-03-16 15:02:32解释LangChain框架中的Chain和Agent概念，并举例说明各自的应用场景上次浏览：2026-03-16 15:02:59什么是大模型的”涌现能力”？列举三种典型表现并解释其可能成因要让AI生成一个带表单验证的Vue3组件，请写出包含以下要素的Prompt上次浏览：2026-03-16 15:06:23假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）上次浏览：2026-03-16 15:07:05请描述使用LangChain构建一个文档问答系统的关键技术组件及实现步骤上次浏览：2026-03-16 15:07:08假设要开发一个智能工单分类系统，请拆解AI可参与的环节并说明技术选型思路11326. 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。本质上是在通用知识的基础上”精雕细琢”，让模型在某个垂直领域表现得更专业。微调的核心原理是迁移学习。预训练模型已经在海量数据上学会了语言的通用规律，微调就是在这个基础上，用少量的领域数据让模型学会特定领域的表达方式和知识。打个比方，预训练模型像是读完了整个图书馆的通才，微调就是让它去医院实习三个月，变成一个懂医学的通才。什么时候需要微调而不是直接用基础模型？主要看这几种情况：1）专业领域应用。比如医疗诊断、法律咨询这类场景，GPT 对骨科、心内科的专业术语和诊疗逻辑掌握得不够深，直接拿来用容易出错。这时候用 10 万条专科病历数据做微调，准确率能从 60% 提到 90% 以上。

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

来源: 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？.mhtml

关键点#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？#
问题#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。
本质上是在通用知识的基础上”精雕细琢”，让模型在某个垂直领域表现得更专业。
微调的核心原理是迁移学习。

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

标准回答#
问题#

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

来源: 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？.mhtml

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？#
- 问题#

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

- 大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。
本文已做格式统一与噪声清理，保留原始语义。
请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？
请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？#
1. 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。本质上是在通用知识的基础上”精雕细琢”，让模型在某个垂直领域表现得更专业。微调的核心原理是迁移学习。预训练模型已经在海量数据上学会了语言的通用规律，微调就是在这个基础上，用少量的领域数据让模型学会特定领域的表达方式和知识。打个比方，预训练模型像是读完了整个图书馆的通才，微调就是让它去医院实习三个月，变成一个懂医学的通才。什么时候需要微调而不是直接用基础模型？主要看这几种情况：1）专业领域应用。比如医疗诊断、法律咨询这类场景，GPT 对骨科、心内科的专业术语和诊疗逻辑掌握得不够深，直接拿来用容易出错。这时候用 10 万条专科病历数据做微调，准确率能从 60% 提到 90% 以上。

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

微调的过拟合风险如何通过正则化缓解？上次浏览：2026-03-16 15:06:11请详细讨论微调时如何防止灾难性遗忘问题？在多模态微调（如图文生成）中，如何确保文本和图像数据的对齐质量？上次浏览：2026-03-16 15:02:13请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？上次浏览：2026-03-16 15:02:32解释LangChain框架中的Chain和Agent概念，并举例说明各自的应用场景上次浏览：2026-03-16 15:02:59什么是大模型的”涌现能力”？列举三种典型表现并解释其可能成因要让AI生成一个带表单验证的Vue3组件，请写出包含以下要素的Prompt上次浏览：2026-03-16 15:06:23假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）上次浏览：2026-03-16 15:07:05请描述使用LangChain构建一个文档问答系统的关键技术组件及实现步骤上次浏览：2026-03-16 15:07:08假设要开发一个智能工单分类系统，请拆解AI可参与的环节并说明技术选型思路11326. 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？大模型微调是在预训练模型的基础上，用特定领域的数据集继续训练，让模型的权重朝着目标任务的方向调整。本质上是在通用知识的基础上”精雕细琢”，让模型在某个垂直领域表现得更专业。微调的核心原理是迁移学习。预训练模型已经在海量数据上学会了语言的通用规律，微调就是在这个基础上，用少量的领域数据让模型学会特定领域的表达方式和知识。打个比方，预训练模型像是读完了整个图书馆的通才，微调就是让它去医院实习三个月，变成一个懂医学的通才。什么时候需要微调而不是直接用基础模型？主要看这几种情况：1）专业领域应用。比如医疗诊断、法律咨询这类场景，GPT 对骨科、心内科的专业术语和诊疗逻辑掌握得不够深，直接拿来用容易出错。这时候用 10 万条专科病历数据做微调，准确率能从 60% 提到 90% 以上。

1）数据质量比数量重要得多。1000 条高质量的 instruction 数据，效果可能比 10 万条噪声数据好。数据里如果有矛盾的标注，模型会学得很混乱。

4）过拟合。小数据集微调几轮效果很好，多跑几轮反而变差。一般 3-5 个 epoch 就够了，超过 10 个 epoch 基本都是在过拟合。

提问：LoRA 的低秩分解具体是怎么工作的？为什么能省这么多参数？回答：LoRA 的核心思路是，微调过程中权重的变化量是低秩的，不需要更新整个权重矩阵。假设原始权重矩阵 W 是 d×k 维，LoRA 把增量 ΔW 分解成两个小矩阵 A（d×r）和 B（r×k）的乘积，r 通常取 8 或 16，远小于 d 和 k。这样可训练参数从 d×k 变成 d×r + r×k，比如 4096×4096 的矩阵用 rank=16，参数量从 1600 万降到 13 万，压缩了 100 多倍。推理时把 BA 加回原始权重就行，不增加推理延迟。- 提问：怎么判断一个任务应该用微调还是 RAG？
回答：看任务的核心瓶颈在哪。如果是知识不够，比如模型不知道公司内部的产品文档、最新的法规政策，用 RAG 更合适，知识更新也方便。如果是能力不够，比如模型不会按特定格式输出、不会做某种类型的推理，那得微调，RAG 再怎么检索也补不上能力短板。还有一个考量是实时性，RAG 的知识库可以随时更新，微调一次成本高、周期长。- 提问：微调后模型效果变差了，怎么排查？
回答：首先看训练数据有没有问题，比如标注错误、格式不对、数据重复。然后看学习率是不是太大了，可以降到原来的 1/5 试试。再看有没有过拟合，训练 loss 一直降但验证 loss 开始上升就是过拟合了，减少 epoch 或者加 dropout。最后检查是不是灾难性遗忘，用原来预训练模型擅长的任务测一下，如果这些任务也变差了，说明微调数据太单一，需要混入通用数据。

微调的底层原理

来源: 请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？.mhtml
本文已做格式统一与噪声清理，保留原始语义。

长上下文openclaw如何处理整理

Wed, 10 Jun 2026 00:00:00 GMT

长上下文openclaw如何处理#

问题#

长上下文openclaw如何处理

标准回答#

LLM的上下文窗口有限，长对话时容易”爆窗”，导致请求失败或Agent”失忆”。

OpenClaw的四层防护机制 Context Pruning（上下文修剪） - 轻量修剪

作用：定期清理早期、不重要的内容
关键策略：
保护系统提示和最近3轮对话（保持连贯性）
裁剪早期的工具返回结果
分两级阈值：30%时裁剪，50%时替换为占位符
类比：清理手机缓存，保留核心应用 Tool Result Context Guard（工具返回兜底） - 实时防护
作用：发送给LLM前最后一层安全检查
工作流程：计算可用预算 = 窗口大小 × 0.75（预留余量）截断超长的单条工具返回（优先保留错误信息）如总量仍超，替换最早的旧结果
价值：确保永远不会因工具返回过大而请求失败 Memory Flush（记忆刷盘） - 关键信息备份
触发：在准备压缩前
操作：Agent自主将关键信息写到文件（memory/YYYY-MM-DD.md）
目的：防止压缩时丢失重要细节 Compaction（压缩） - 历史对话摘要
方法：用LLM将100条对话压缩成一段摘要
优化：采用”滚动摘要”，摘要也可被再次压缩
保护：要求保留URL、文件名等不可重建的标识符

设计亮点

分层渐进

从轻到重，避免过早使用”重”压缩
能小修就不大动

智能截断

工具返回截断时，检测并优先保留错误信息
避免”执行200行日志，最后报错”被误判为成功

时间与空间平衡

Context Pruning处理早期空间（旧内容）
Memory Flush处理关键信息（语义记忆）
Compaction处理时间序列（历史对话）

回答示例

面试官：长对话时如何保证Agent不”失忆”？

您可以回答：

OpenClaw采用四层渐进式防御策略：日常修剪：定期清理早期的工具返回，但保留核心指令和最近对话实时兜底：每次发请求前做安全检查，保证不超窗口限制关键备份：压缩前先把重要信息存到文件历史压缩：用LLM把长对话压缩成摘要

这四层分别对应：空间清理、实时防护、信息备份、时间压缩。既保证不”失忆”，又控制成本。

面试官追问#

如果压缩时丢了重要信息怎么办？

您可以回答：

这是分层防御的价值所在。压缩前有Memory Flush，让Agent自己决定什么重要，先存到文件。压缩后有标识符保留，不会丢失文件名、URL这类关键引用。即使真的需要原始信息，文件类的结果可以重新读取工具获取。这个解释层次清晰，突出了OpenClaw的核心设计理念：分层、渐进、有保障。

关键点#

LLM的上下文窗口有限，长对话时容易”爆窗”，导致请求失败或Agent”失忆”。
OpenClaw的四层防护机制 Context Pruning（上下文修剪） - 轻量修剪
作用：定期清理早期、不重要的内容
关键策略：
保护系统提示和最近3轮对话（保持连贯性）
裁剪早期的工具返回结果
分两级阈值：30%时裁剪，50%时替换为占位符
类比：清理手机缓存，保留核心应用 Tool Result Context Guard（工具返回兜底） - 实时防护
作用：发送给LLM前最后一层安全检查
工作流程：计算可用预算 = 窗口大小 × 0.75（预留余量）截断超长的单条工具返回（优先保留错误信息）如总量仍超，替换最早的旧结果
价值：确保永远不会因工具返回过大而请求失败 Memory Flush（记忆刷盘） - 关键信息备份
触发：在准备压缩前
操作：Agent自主将关键信息写到文件（memory/YYYY-MM-DD.md）
目的：防止压缩时丢失重要细节 Compaction（压缩） - 历史对话摘要
方法：用LLM将100条对话压缩成一段摘要
优化：采用”滚动摘要”，摘要也可被再次压缩
保护：要求保留URL、文件名等不可重建的标识符

设计亮点

分层渐进

从轻到重，避免过早使用”重”压缩
能小修就不大动

智能截断

工具返回截断时，检测并优先保留错误信息
避免”执行200行日志，最后报错”被误判为成功

时间与空间平衡

Context Pruning处理早期空间（旧内容）
Memory Flush处理关键信息（语义记忆）
Compaction处理时间序列（历史对话）

回答示例

面试官：长对话时如何保证Agent不”失忆”？

您可以回答：

这四层分别对应：空间清理、实时防护、信息备份、时间压缩。

既保证不”失忆”，又控制成本。

如果压缩时丢了重要信息怎么办？

备注#

本文已做格式统一与噪声清理，保留原始语义。
问题#

长上下文openclaw如何处理

LLM的上下文窗口有限，长对话时容易”爆窗”，导致请求失败或Agent”失忆”。

OpenClaw的四层防护机制 Context Pruning（上下文修剪） - 轻量修剪
作用：定期清理早期、不重要的内容
关键策略：
保护系统提示和最近3轮对话（保持连贯性）
裁剪早期的工具返回结果
分两级阈值：30%时裁剪，50%时替换为占位符
类比：清理手机缓存，保留核心应用 Tool Result Context Guard（工具返回兜底） - 实时防护
作用：发送给LLM前最后一层安全检查
工作流程：计算可用预算 = 窗口大小 × 0.75（预留余量）截断超长的单条工具返回（优先保留错误信息）如总量仍超，替换最早的旧结果
价值：确保永远不会因工具返回过大而请求失败 Memory Flush（记忆刷盘） - 关键信息备份
触发：在准备压缩前
操作：Agent自主将关键信息写到文件（memory/YYYY-MM-DD.md）
目的：防止压缩时丢失重要细节 Compaction（压缩） - 历史对话摘要
方法：用LLM将100条对话压缩成一段摘要
优化：采用”滚动摘要”，摘要也可被再次压缩
保护：要求保留URL、文件名等不可重建的标识符

设计亮点

分层渐进

从轻到重，避免过早使用”重”压缩
能小修就不大动

智能截断

工具返回截断时，检测并优先保留错误信息
避免”执行200行日志，最后报错”被误判为成功

时间与空间平衡

Context Pruning处理早期空间（旧内容）
Memory Flush处理关键信息（语义记忆）
Compaction处理时间序列（历史对话）

回答示例

面试官：长对话时如何保证Agent不”失忆”？

您可以回答：

这四层分别对应：空间清理、实时防护、信息备份、时间压缩。既保证不”失忆”，又控制成本。#

如果压缩时丢了重要信息怎么办？

您可以回答：

这是分层防御的价值所在。压缩前有Memory Flush，让Agent自己决定什么重要，先存到文件。压缩后有标识符保留，不会丢失文件名、URL这类关键引用。即使真的需要原始信息，文件类的结果可以重新读取工具获取。

本文已做格式统一与噪声清理，保留原始语义。
长上下文openclaw如何处理
LLM的上下文窗口有限，长对话时容易”爆窗”，导致请求失败或Agent”失忆”。
OpenClaw的四层防护机制
1. Context Pruning（上下文修剪） - 轻量修剪
- 作用：定期清理早期、不重要的内容
本文已做格式统一与噪声清理，保留原始语义。

阿里AI应用研发实习一面

Wed, 10 Jun 2026 00:00:00 GMT

阿里 AI 应用研发实习一面面经#

来源：小红书 @未知作者原文链接：https://www.xiaohongshu.com/discovery/item/6a054355000000003501fec8 发布时间：2026-01-30 标签：面经、面试题、互联网大厂、AI Agent、RAG、JVM

一、AI Agent 相关#

AI Agents 和大模型的本质区别是什么？
- Agent 相比单纯的大模型对话进化在哪些方面？
什么是 ReAct 框架？
- 它的工作原理是什么？解决了什么问题？
Agent 的 Memory（记忆）机制有哪些？
- 请简要说明。

二、RAG（检索增强生成）相关#

RAG 解决了大模型中的哪些问题？
RAG 系统中文档分块的策略有哪些？
- 如何选择适合自己的分块方式？
如何评估一个 RAG 系统的检索质量？
- 追问：只看召回率吗？
检索阶段的常见瓶颈是什么？
- 如何定位问题？
微调（Fine-tuning）与 RAG 的区别是什么？
- 各自适合什么场景？在实际项目中如何决策？

三、Java / JVM 基础#

一个 Java 进程从启动后，其内存对象大概是如何分布的？
函数的临时变量存放在哪里？
- 栈和堆是如何关联的？
你用过或了解哪些垃圾回收算法？
- 最常用的是哪一种？
- 追问：JVM 参数中可配置的 GC 算法/回收器。

四、AI coding#

面试官在 AI coding 环节没有直接评价完成质量，但进行了以下深入追问：
- 询问对题目的理解
- 完成后要做什么（比如测试）
- 开发过程中是否存在问题

大模型Transformer高频面试题

Wed, 10 Jun 2026 00:00:00 GMT

大模型 & Transformer 高频面试题及答案#

🎯 适用岗位：算法工程师、AI 应用开发、大模型研发 📅 整理日期：2026-06-07 💬 答案按面试口语化写，直接照着说就行

一、Transformer 核心架构#

Q1：Transformer 的基本结构是什么？#

Transformer 分两半——Encoder 和 Decoder，每半都是 N 个一样的层叠在一起。

单层 Encoder 就是：多头注意力 → 残差+归一化 → 前馈网络 → 残差+归一化。

Decoder 多了一步：先是带 mask 的自注意力（只能看当前和之前的 token），然后是交叉注意力（去拿 Encoder 的信息），最后才是前馈网络。

现在主流大模型分三种路线：

BERT 那种只用 Encoder：双向注意力，擅长理解类任务，比如分类、实体识别
GPT/LLaMA 那种只用 Decoder：单向注意力，擅长生成
T5 那种 Encoder+Decoder：适合翻译、摘要这种输入输出都很长的任务

追问：为什么现在大模型几乎都用 Decoder-only？

主要几个原因：一是自回归的训练目标和推理完全一致，训练效率高；二是单向注意力天然适配 next-token prediction；三是工程上更简单，推理时 KV Cache 处理更自然；四是实验发现同等参数量下 Decoder-only 的 scaling 效果更好。

Q2：Transformer 相比 RNN/LSTM 有什么优势？#

最核心的就两点：并行和长距离依赖。

RNN 必须一个 token 一个 token 顺序算，没法并行，GPU 利用率低。Transformer 的注意力机制所有位置可以同时算，训练速度差了好几倍。

另外 RNN 处理长序列容易梯度消失，远处的信息传着传着就丢了。Transformer 的注意力是直接”看”到所有位置的，不管隔多远都是一步到位。

当然 Transformer 也有代价——注意力是 O(n²) 的复杂度，序列越长越吃内存，但总体来说在 GPU 上训练还是比 RNN 快得多。

二、Self-Attention 机制#

Q3：Self-Attention 的计算流程是什么？#

简单说就三步：

输入先过三个线性层，分别得到 Q（查询）、K（键）、V（值）
Q 和 K 做点积算相似度，除以 √d_k 缩放一下，过 softmax 得到注意力权重
用权重对 V 做加权求和，得到输出

用公式说就是：Attention(Q,K,V) = softmax(Q·K^T / √d_k) · V

直觉上理解：Q 是”我想找什么”，K 是”我有什么”，Q·K^T 算的是匹配程度，V 是”找到之后给你什么内容”。

Q4：为什么要除以 √d_k？⭐超高频#

因为 d_k 一大，Q 和 K 的点积值就会变得很大，softmax 一收到很大的输入，输出就几乎变成 one-hot 了——只有一个位置接近 1，其他都接近 0。这时候梯度几乎为 0，模型就训不动了。

除以 √d_k 就是把点积值”拉回”正常范围，让 softmax 的输出更平滑，梯度能正常传播。

数学上解释的话：假设 Q 和 K 的每个元素都是均值为 0、方差为 1 的，那点积的方差就是 d_k，除以 √d_k 之后方差就归一化回 1 了。

Q5：Multi-Head Attention 的作用是什么？#

多头注意力就是让模型同时从不同角度去看输入。每个头学到的注意力模式不一样——有的头关注语法关系，有的关注语义关系，有的关注相邻词，有的关注远距离依赖。

如果只用一个大头，它只能学一种模式；用多个小头，每个头可以专门化，最后拼起来信息更丰富。

而且多头在计算上也更高效：每个头的维度是 d_model/h，多个头可以并行算，总计算量和单头差不多。

Q6：MHA / MQA / GQA 的区别？⭐高频#

这三个的区别就在于 K 和 V 是不是共享的：

MHA（多头注意力）：每个头都有自己的 Q、K、V，效果最好但 KV Cache 最大，推理最慢
MQA（多查询注意力）：Q 还是每个头独立，但 K 和 V 所有头共享一份，推理最快但效果会掉一点
GQA（分组查询注意力）：折中方案，把头分成几组，组内共享 K 和 V。比如 8 个头分 2 组，每组 4 个头共享一组 K、V

现在主流模型基本都选 GQA，比如 LLaMA-2/3、Mistral，用很小的质量损失换来了显著的推理加速和内存节省。

三、位置编码#

Q7：为什么 Transformer 需要位置编码？#

因为 Self-Attention 是”不分先后”的——你把输入的顺序打乱，Attention 算出来的结果只是对应位置换了一下，模型根本不知道谁在前谁在后。

“猫吃鱼”和”鱼吃猫”对 Attention 来说是一样的，这显然不行。所以得额外告诉模型每个 token 在哪个位置，这就是位置编码。

Q8：RoPE 旋转位置编码是什么？为什么现在主流都用它？#

位置编码分几代：

绝对位置编码（BERT 用的）：给每个位置一个固定向量，简单但超出训练长度就不行了
相对位置编码（T5 用的）：编码的是两个 token 之间的距离，外推性好但实现复杂
RoPE（LLaMA、Qwen 用的）：用旋转矩阵把位置信息”转”进 Q 和 K 里，这样 Q·K^T 的点积天然就包含了相对位置信息

RoPE 厉害的地方在于它统一了绝对和相对位置编码的优点——实现简单，外推性好，所以现在基本是大模型的标配。

四、KV Cache 与推理优化#

Q9：什么是 KV Cache？为什么需要它？⭐超高频#

大模型生成文本是一个 token 一个 token 往外蹦的。每生成一个新 token，都要用前面所有 token 的 K 和 V 来算注意力。

问题是：前面那些 token 的 K 和 V 其实不会变，每次重新算是纯浪费。所以就把算过的 K 和 V 缓存起来，下次直接用，只算新 token 的就行。

没有 KV Cache 的话，生成第 t 个 token 要重新算前 t-1 个，复杂度是 O(t²)；有了之后只算当前 token 的，复杂度降到 O(t)。推理速度能快 5-10 倍，现在所有线上服务的大模型都用这个。

Q10：为什么缓存 K 和 V，不缓存 Q？⭐超高频#

因为历史 token 的 K 和 V 在后续每一步都要被”查”到——新 token 的 Q 要和所有历史 token 的 K 算相似度，再用权重去取历史 token 的 V。所以缓存 K 和 V 有实实在在的收益。

但 Q 不一样——每个 token 的 Q 只在当前这一步用，下一步的 Q 是新 token 产生的，跟之前的 Q 没关系。所以缓存 Q 没有任何加速效果，不是”不能”缓存，是缓存了也没用。

Q11：常见的推理加速方法有哪些？#

主要有这几个：

KV Cache：缓存历史 K/V 避免重复计算，5-10 倍加速，没有精度损失
量化：把模型权重从 FP16 压到 INT8 甚至 INT4，2-4 倍加速，精度损失很小
GQA/MQA：减少 K/V 的头数，降低内存和计算量，1.5-3 倍加速
Speculative Decoding（投机解码）：用小模型先猜几个 token，大模型并行验证，猜对了就一次接受多个，2-3 倍加速，精度无损
Continuous Batching：动态把不同请求拼在一起，提高 GPU 利用率，吞吐能翻好几倍

五、大模型训练与对齐#

Q12：大模型的训练流程是什么？#

分三步走：预训练 → SFT → RLHF/DPO

预训练：用海量无标注文本（万亿级 token），目标是 next-token prediction。这一步最贵，烧掉 99% 的算力和数据，让模型学会语言的基本规律和世界知识。

SFT（有监督微调）：用几万条高质量的”指令-回答”对，教模型听懂人的指令、按格式回答。这一步成本中等，但很关键，是从”语言模型”变成”助手”的关键一步。

RLHF/DPO（对齐训练）：用人类偏好数据，让模型的回答更符合人的价值观——更有用、更安全、更诚实。这一步成本相对低，但决定了模型的”性格”。

Q13：RLHF 的流程是什么？#

两步：

第一步，训练奖励模型：让人对同一个问题的多个回答排序，用这些排序数据训练一个打分模型，它能给回答打出一个”人类偏好分数”。

第二步，用 PPO 强化学习优化：让大模型生成回答，奖励模型打分，用 PPO 算法根据分数更新大模型。同时加一个 KL 散度惩罚，防止模型为了拿高分而变得太极端。

RLHF 的问题：奖励模型可能被”钻空子”（reward hacking），PPO 训练不稳定、超参难调，而且需要同时跑 4 个模型（策略模型、参考模型、奖励模型、价值模型），显存开销很大。

Q14：DPO 和 RLHF 的区别？⭐高频#

DPO 本质上是 RLHF 的简化版。

RLHF 要两步：先训练奖励模型，再用 PPO 做强化学习。DPO 把这两步合成一步——直接用人类偏好数据（好回答 vs 差回答）来优化策略模型，不需要单独的奖励模型，也不需要 PPO。

好处很明显：训练更稳定（不像 PPO 那么多超参要调），只需要 2 个模型而不是 4 个，实现也简单得多。

所以现在 DPO 基本成了对齐训练的主流选择，除非有特殊需求才会用 RLHF。

Q15：LoRA 的原理是什么？⭐高频#

LoRA 的核心想法是：微调时不直接改原始权重，而是加一个低秩的”补丁”。

原始是 Y = X·W，LoRA 变成 Y = X·(W + B·A)，其中 B 和 A 是两个很小的矩阵，秩 r 远小于原始维度。

举个例子：如果原始权重是 4096×4096，有 1600 万参数；LoRA 用秩 8 的话，B 是 4096×8，A 是 8×4096，加起来才 6.5 万参数，减少了 99.6%。

关键优势：一是训练参数极少，单卡就能微调大模型；二是推理时可以把 B·A 合并回 W，没有任何额外延迟；三是不同任务可以训练不同的 LoRA，随时切换。

六、大模型架构与应用#

Q16：MoE（混合专家）是什么？#

MoE 的思路是：模型参数可以很大，但每个 token 只激活其中一小部分。

具体来说，每一层有多个”专家”（其实就是多个前馈网络），来一个 token 先过路由器（Gate），路由器选出最合适的 Top-K 个专家，只让这几个专家算，最后把结果加权求和。

比如 Mixtral 8×7B，总参数 46.7B，但每个 token 只用 12.9B 的参数，计算量跟 13B 的稠密模型差不多，效果却接近 47B 的。

挑战主要是：负载均衡（别让所有 token 都挤到同一个专家）、多卡通信开销大、显存占用还是按总参数来的。

Q17：RAG 和微调的区别？怎么选？⭐高频#

RAG 是给模型外挂一个知识库，每次提问先检索相关内容，塞进 prompt 里让模型基于检索结果回答。微调是用特定数据继续训练模型，把知识”写进”权重里。

核心区别：

知识更新：RAG 改检索库就行，实时更新；微调得重新训练
幻觉控制：RAG 有检索结果做依据，幻觉少；微调全靠模型”记忆”，容易编
成本：RAG 不用训练，成本低；微调要 GPU 和数据
擅长的事：RAG 擅长知识密集型问答，微调擅长调整风格、格式、特定能力

选哪个？需要实时知识就 RAG，需要特定风格/能力就微调，两者都要就 RAG + 微调一起上。

Q18：大模型的幻觉问题怎么缓解？#

大模型幻觉的根本原因是：它是概率语言模型，不是知识库，生成的是”看起来合理”的文本，不保证事实正确。

缓解方法：

RAG：最直接，给模型提供外部知识做依据，效果最好
CoT（思维链）：让模型一步步推理，中间步骤可以检查，减少跳步出错
对齐训练：RLHF/DPO 训练时惩罚幻觉输出，让模型学会说”我不知道”
系统提示：在 prompt 里明确要求”不确定就说不知道”，简单但有效

实际中一般是 RAG + CoT + 对齐训练三板斧一起用。

Q19：什么是思维链（CoT）？#

CoT 就是让模型把推理过程写出来，而不是直接给答案。

有几种用法：

Zero-shot CoT：最简单，在 prompt 末尾加一句”Let’s think step by step”，模型就会自动展开推理
Few-shot CoT：给几个带推理过程的示例，模型照着格式来
Self-Consistency：多次采样取多数结果，更可靠但更慢

为什么 CoT 有效？因为复杂问题一步算出来容易错，拆成多个简单步骤每步出错的概率就低多了。而且中间步骤可以人工检查，方便定位问题。

🎯 速记口诀#

1
Transformer 核心：Self-Attention + 位置编码 + 残差 + LayerNorm
2
Attention 缩放：除以 √d_k，不然 softmax 变 one-hot，梯度消失
3
位置编码：RoPE 是主流，统一绝对+相对
4
KV Cache：缓存历史 K/V 省重复计算，Q 不用缓存因为只用一次
5
MHA→GQA：质量和速度的折中，LLaMA-2/3 的选择
6
训练三步曲：预训练 → SFT → RLHF/DPO
7
DPO vs RLHF：DPO 不需要奖励模型，更简单稳定
8
LoRA：低秩补丁，训练 0.1% 参数，推理零延迟
9
RAG vs 微调：要实时知识用 RAG，要风格能力用微调
10
幻觉缓解：RAG + CoT + 对齐训练 三板斧

ping curl 排查面试题

Wed, 10 Jun 2026 00:00:00 GMT

Ping / Curl 服务不通 —— 面试高频问题及答案#

🎯 适用岗位：运维工程师、SRE、后端开发、网络工程师 📅 整理日期：2026-06-07

一、核心概念：ping 和 curl 到底有什么区别？#

维度	ping	curl
协议	ICMP（网络层）	HTTP/HTTPS（应用层，底层走 TCP）
能测什么	主机是否在线、网络是否可达	服务端口是否开放、HTTP 服务是否正常响应
不能测什么	端口状态、服务状态	—
常被拦截	ICMP 常被防火墙/云安全组禁掉	TCP 端口可能被防火墙/安全组拦截

面试关键句：ping 通只说明 ICMP 可达，不代表服务可用；ping 不通也不代表服务不可用，可能只是 ICMP 被禁。

二、六大经典场景 Q&A#

Q1：能 ping 通，但 curl 不通，可能的原因有哪些？#

答案（按排查优先级排列）：

服务未启动 / 端口未监听
- ping 走 ICMP，只验证主机在线；curl 走 TCP，需要目标端口有进程监听
- 排查：ss -tlnp | grep <端口> 或 netstat -tlnp | grep <端口>
防火墙 / 安全组只放行了 ICMP，未放行 TCP 端口
- 云服务器安全组常见：只允许 ping（ICMP），未开放 80/443 等端口
- 排查：iptables -L -n 检查本地防火墙；云控制台检查安全组规则
服务只监听了 127.0.0.1（localhost），未监听 0.0.0.0
- 服务绑定在回环地址，外部无法访问
- 排查：ss -tlnp 看监听地址是 127.0.0.1:8080 还是 0.0.0.0:8080
DNS 解析异常
- ping 可能走了 /etc/hosts 或不同 DNS，curl 解析到了错误 IP
- 排查：nslookup 域名 / dig 域名，对比 ping 和 curl 解析的 IP 是否一致
代理配置干扰
- curl 默认读取 http_proxy / https_proxy 环境变量，可能走了代理
- 排查：curl -v --noproxy '*' URL 跳过代理测试
HTTPS 证书问题
- curl 访问 HTTPS 时证书校验失败（自签证书、过期、域名不匹配）
- 排查：curl -kv URL 跳过证书验证测试
服务端拦截了 User-Agent 或请求头
- 某些 WAF / CDN 会拦截非浏览器的请求
- 排查：curl -A "Mozilla/5.0" URL 伪装 UA 测试

Q2：ping 不通，但 curl 能通，可能的原因？#

答案：

ICMP 被防火墙 / 安全组禁掉（最常见）
- 云服务器默认可能禁 ping；运维出于安全考虑主动禁 ICMP
- 这是正常现象，不代表服务有问题
内核参数禁用了 ICMP 响应
- net.ipv4.icmp_echo_ignore_all = 1
- 排查：sysctl net.ipv4.icmp_echo_ignore_all
中间路由器丢弃 ICMP 包
- 某些网络设备/运营商策略丢弃 ICMP，但放行 TCP
- 排查：traceroute IP 看在哪一跳开始丢包

面试关键句：ping 不通 ≠ 服务不可用，生产环境中 ICMP 被禁是常态，应以 TCP 端口连通性为准。

Q3：ping 和 curl 都不通，怎么排查？#

答案（分层排查法，从底层到上层）：

1
物理层 → 数据链路层 → 网络层 → 传输层 → 应用层

Step 1：检查本机网络

Terminal window

1
ping 127.0.0.1        # 回环地址，验证 TCP/IP 协议栈
2
ping 本机IP            # 验证网卡配置
3
ping 默认网关          # 验证到网关的连通性

Step 2：检查路由

Terminal window

1
traceroute 目标IP      # 看数据包卡在哪一跳
2
mtr 目标IP             # 实时跟踪，比 traceroute 更好用
3
route -n               # 查看路由表

Step 3：检查 DNS

Terminal window

1
nslookup 域名          # DNS 能否解析
2
ping 域名 vs ping IP   # 如果 IP 能通但域名不通 → DNS 问题

Step 4：检查端口连通性

Terminal window

1
telnet 目标IP 端口     # 测试 TCP 端口是否开放
2
nc -zv 目标IP 端口     # 更灵活的端口探测

Step 5：检查防火墙 / 安全组

Terminal window

1
iptables -L -n         # 本地防火墙规则
2
# 云平台：检查安全组入方向规则

Step 6：检查服务本身

Terminal window

1
ss -tlnp               # 服务是否在监听
2
systemctl status 服务名  # 服务是否运行
3
journalctl -u 服务名    # 查看服务日志

Q4：如何判断是服务端问题还是客户端问题？#

答案：

排查手段	服务端问题	客户端问题	中间网络问题
从其他机器 curl 同一地址	也不通	能通	部分能通
telnet/nc 测端口	连接被拒	超时	超时
traceroute	到达目标后丢包	第一跳就丢	中间某跳丢包
服务端 ss -tlnp	端口未监听	端口正常监听	端口正常监听
服务端日志	有报错	无异常	无异常

快速判断口诀：

Connection refused → 服务端没监听（服务端问题）
Connection timeout → 防火墙拦截 / 路由不通（中间网络或客户端问题）
只有自己不通 → 客户端问题（本地防火墙/代理/DNS）

Q5：curl 返回常见错误码的含义？#

错误码	含义	排查方向
`curl: (6) Could not resolve host`	DNS 解析失败	检查 DNS 配置、/etc/hosts
`curl: (7) Failed to connect`	TCP 连接失败	端口未开放/防火墙拦截
`curl: (28) Connection timed out`	连接超时	防火墙丢包/路由不可达
`curl: (35) SSL connect error`	SSL/TLS 握手失败	证书问题/协议版本不匹配
`curl: (52) Empty reply from server`	服务端断开连接	服务崩溃/负载均衡异常
`curl: (56) Recv failure`	接收数据失败	服务端异常关闭连接
HTTP 403	禁止访问	权限/WAF 拦截
HTTP 502	网关错误	上游服务不可用
HTTP 503	服务不可用	服务过载/维护中

Q6：生产环境如何快速定位网络问题？#

答案（三板斧）：

斧一：curl -v（详细模式）

Terminal window

1
curl -v http://目标地址:端口/路径

能看到：DNS 解析 → TCP 连接 → TLS 握手 → HTTP 请求/响应的每一步，卡在哪一目了然。

斧二：tcpdump（抓包分析）

Terminal window

1
# 客户端抓包
2
tcpdump -i any host 目标IP and port 目标端口 -nn
3

4
# 服务端抓包
5
tcpdump -i any host 客户端IP and port 服务端口 -nn

客户端有 SYN，服务端没收到 → 中间网络丢包
服务端收到 SYN 但没回 SYN-ACK → 防火墙拦截
三次握手完成但数据传输异常 → 应用层问题

斧三：mtr（持续链路追踪）

Terminal window

1
mtr -rwbz 目标IP

集成了 traceroute + ping，能看到每一跳的丢包率和延迟，定位问题节点。

三、面试加分项#

1. 画一张排查流程图#

1
服务不通
2
  │
3
  ├─ ping 通？
4
  │    ├─ 是 → ICMP 可达，问题在 TCP/应用层
5
  │    │         ├─ telnet/nc 测端口
6
  │    │         │    ├─ 通 → 服务本身问题（日志/配置/代码）
7
  │    │         │    └─ 不通 → 防火墙/安全组/服务未启动
8
  │    │         └─ curl -v 看具体卡在哪步
9
  │    │
10
  │    └─ 否 → ICMP 也不通
11
  │              ├─ ping 网关通？→ 路由问题
12
  │              ├─ ping IP 通但域名不通？→ DNS 问题
13
  │              ├─ traceroute 看卡在哪跳 → 中间网络问题
14
  │              └─ 确认 ICMP 是否被禁（curl/telnet 测端口）
15
  │
16
  └─ 记住：永远以 TCP 连通性为准，ICMP 只是辅助

Show moreShow less

2. 云环境特殊注意点#

安全组：入方向规则必须放行对应端口
网络 ACL：子网级别的访问控制，比安全组优先级更高
NAT 网关：影响出方向访问
负载均衡：健康检查失败会导致后端被摘除，curl 返回 502/503
CDN：缓存/回源问题可能导致部分节点不通

3. 一句话总结（面试收尾用）#

“排查网络问题的核心思路是分层排查——从物理层到应用层逐层验证，用 curl -v 定位卡点，用 tcpdump 确认包是否到达，用 mtr 追踪链路。ping 只是辅助工具，生产环境以 TCP 端口连通性为准。“

四、速记口诀#

1
ping 通 curl 不通 → 端口没开 / 防火墙拦 / 监听 127.0.0.1
2
ping 不通 curl 通 → ICMP 被禁（正常现象）
3
都不通 → 分层查：本机→网关→DNS→路由→防火墙→服务
4
Connection refused → 服务端没监听
5
Connection timeout → 防火墙/路由问题
6
curl -v 是万能第一步

DS2API 部署使用指南

Wed, 10 Jun 2026 00:00:00 GMT

ds2api 部署使用指南#

将 DeepSeek Web 对话能力转换为 OpenAI、Claude、Gemini 兼容 API 的中间件。项目地址：https://github.com/CJackHwang/ds2api （v4.6.1，已归档只读）

一、项目简介#

ds2api 是一个用 Go 编写的 DeepSeek Web → OpenAI 兼容 API 代理。它通过模拟 DeepSeek 网页端的对话流程，把网页能力转为标准 API 接口，支持：

OpenAI /v1/chat/completions（含流式响应）
Claude /v1/messages
Gemini /v1beta/models/.../generateContent
WebUI 管理台（React 前端）

与 qoder-cn-proxy 的区别： qoder-cn-proxy 调用的是 Qoder CN 官方 API（需要 PAT Token）；ds2api 模拟的是 DeepSeek 网页端对话（需要 DeepSeek 账号密码）。

二、部署环境要求#

项目	要求
操作系统	Alpine Linux（proot 环境）
Go	>= 1.26.0（Alpine 自带的 1.23 不够）
架构	ARM64（手机 CPU）
DeepSeek 账号	邮箱+密码或手机号+密码

三、部署步骤#

1. 安装 Go 1.26.0#

Alpine 自带的 Go 1.23 版本太低，需要手动安装 Go 1.26：

Terminal windowShow moreShow less

1
# 用 Python 下载并解压（比 curl 在 proot 中更稳定）
2
python3 -c "
3
import urllib.request, tarfile
4
url = 'https://dl.google.com/go/go1.26.0.linux-arm64.tar.gz'
5
out = '/tmp/go1.26.0.linux-arm64.tar.gz'
6
print('下载 Go 1.26.0...')
7
req = urllib.request.Request(url, headers={'User-Agent': 'curl/7.0'})
8
data = urllib.request.urlopen(req, timeout=600)
9
with open(out, 'wb') as f:
10
    total = 0
11
    while True:
12
        chunk = data.read(1048576)
13
        if not chunk: break
14
        f.write(chunk)
15
        total += len(chunk)
16
print(f'下载完成: {total/1048576:.1f} MB')
17
print('解压...')
18
with tarfile.open(out, 'r:gz') as tar:
19
    tar.extractall('/usr/local')
20
print('完成')
21
"
22

23
# 验证
24
/usr/local/go/bin/go version
25
# → go version go1.26.0 linux/arm64

Show moreShow less

注意： dl.google.com 在 proot 环境中 TLS 连接比 go.dev 更稳定。如果下载失败，多试几次或换网络。

2. 获取源码#

Terminal window

1
cd /workspace
2

3
# 方式 A：Git 克隆（可能遇到 TLS 错误）
4
git clone https://github.com/CJackHwang/ds2api.git
5

6
# 方式 B：下载 Release 源码包（更可靠）
7
curl -L -o ds2api-v4.6.1.tar.gz "https://github.com/CJackHwang/ds2api/archive/refs/tags/v4.6.1.tar.gz"
8
tar xzf ds2api-v4.6.1.tar.gz
9
mv ds2api-4.6.1 ds2api
10
rm ds2api-v4.6.1.tar.gz

3. 编译#

Terminal window

1
export PATH="/usr/local/go/bin:$PATH"
2
cd /workspace/ds2api
3

4
# 使用 goproxy.cn 国内镜像加速依赖下载
5
GONOSUMCHECK=* GONOSUMDB=* GOPROXY=https://goproxy.cn,direct \
6
  go build -o ds2api ./cmd/ds2api

编译成功后生成 /workspace/ds2api/ds2api（约 25MB，ARM64 ELF）。

4. 配置#

复制示例配置并编辑：

Terminal window

1
cp config.example.json config.json

编辑 config.json，关键字段：

1
{
2
  "keys": ["你的API密钥"],           // 客户端调用时用的 API Key
3
  "api_keys": [
4
    {
5
      "key": "你的API密钥",
6
      "name": "主 API Key",
7
      "remark": "本地使用"
8
    }
9
  ],
10
  "accounts": [
11
    {
12
      "name": "主账号",
13
      "email": "你的DeepSeek邮箱",
14
      "password": "你的DeepSeek密码"
15
      // 或用手机号登录：
16
      // "phone": "你的手机号",
17
      // "phone_code": "国际区号如+86"
18
    }
19
  ],
20
  "model_aliases": {
21
    "gpt-4o": "deepseek-v4-flash",
22
    "gpt-5.5": "deepseek-v4-flash",
23
    "o3": "deepseek-v4-pro"
24
  }
25
  // ... 其他配置保持默认即可
26
}

Show moreShow less

5. 启动#

Terminal window

1
cd /workspace/ds2api
2
./ds2api

启动后监听 http://0.0.0.0:8080（端口见启动日志）。

首次启动注意： 如果提示 [webui] static files missing, running npm build，说明 WebUI 前端静态文件未构建，会自动尝试用 npm 构建。如不需要 WebUI，可忽略此提示。

后台运行（保活）：

Terminal window

1
nohup ./ds2api > /workspace/ds2api/ds2api.log 2>&1 &

或使用 Omnibot 的终端持久会话运行。

四、API 使用#

基本信息#

配置项	值
API Base URL	`http://127.0.0.1:8080`（手机 App 用 localhost）
API Key	config.json 中设置的 key
默认模型	`deepseek-v4-flash`（可通过 model_aliases 映射）

支持的端点#

方法	路径	说明
POST	`/v1/chat/completions`	OpenAI 聊天补全（支持流式）
POST	`/v1/messages`	Claude 消息格式
POST	`/v1beta/models/.../generateContent`	Gemini 格式
GET	`/v1/models`	列出可用模型
GET	`/`	WebUI 管理台

请求示例#

OpenAI 格式（流式）：

Terminal window

1
curl http://127.0.0.1:8080/v1/chat/completions \
2
  -H "Authorization: Bearer 你的API密钥" \
3
  -H "Content-Type: application/json" \
4
  -d '{
5
    "model": "deepseek-v4-flash",
6
    "messages": [{"role": "user", "content": "你好"}],
7
    "stream": true
8
  }'

非流式：

Terminal window

1
curl http://127.0.0.1:8080/v1/chat/completions \
2
  -H "Authorization: Bearer 你的API密钥" \
3
  -H "Content-Type: application/json" \
4
  -d '{
5
    "model": "deepseek-v4-flash",
6
    "messages": [{"role": "user", "content": "你好"}]
7
  }'

客户端配置#

在 ChatGPT 兼容客户端（如 ChatBox、NextChat 等）中：

API 类型： OpenAI Compatible
API Base URL： http://127.0.0.1:8080
API Key： config.json 中设置的 key
Model： deepseek-v4-flash 或 deepseek-v4-pro

五、可用模型#

模型名	别名	说明
`deepseek-v4-flash`	`gpt-4o`, `gpt-5.5`	快速模型，适合日常对话
`deepseek-v4-pro`	`o3`, `gpt-5.3-codex`	高级模型，适合复杂推理

可通过 model_aliases 字段自定义别名映射。

六、目录结构#

1
/workspace/ds2api/
2
├── ds2api              # 编译后的二进制
3
├── config.json         # 运行配置（需手动创建）
4
├── config.example.json # 配置示例
5
├── cmd/ds2api/main.go  # 入口代码
6
├── api/                # API 路由
7
├── app/                # 应用逻辑
8
├── internal/           # 内部包
9
├── webui/              # React 前端
10
├── start.mjs           # Node.js 启动菜单脚本
11
├── go.mod              # Go 模块定义
12
└── go.sum              # Go 依赖校验

七、常见问题#

Q: 启动报错 TLS 连接失败？#

A: DeepSeek 需要通过网络访问其 Web 服务。确保手机网络正常。

Q: 编译时 `go: go.mod requires go >= 1.26.0`？#

A: Alpine 自带的 Go 版本太低（1.23）。需要手动安装 Go 1.26（见步骤 1）。

Q: `GOTOOLCHAIN=auto` 下载 Go 时 Segmentation fault？#

A: proot 环境下 Go 自动工具链下载不稳定。改用手动下载 tar.gz 包安装。

Q: Git clone 报 TLS 错误？#

A: 改用下载 Release 源码包的方式获取代码（方式 B）。

Q: 与 qoder-cn-proxy 有什么区别？#

A: qoder-cn-proxy 调用 Qoder CN 官方 API，需要 PAT Token。ds2api 模拟 DeepSeek 网页端对话，需要 DeepSeek 账号密码。两者是不同的 API 代理方案。

Q: 手机浏览器访问 127.0.0.1:8080 超时？#

A: 在手机浏览器中用 http://127.0.0.1:8080（不要用局域网 IP）。

八、技术架构#

1
客户端 (OpenAI/Claude/Gemini 格式请求)
2
  ↓
3
ds2api (Go 后端, 端口 8080)
4
  ↓ 模拟 DeepSeek Web 协议
5
DeepSeek Web 服务
6
  ↓
7
返回响应 → 转为标准 API 格式返回给客户端

ds2api 本质上是一个 Web 协议适配层，把 DeepSeek 的网页对话协议转换为标准的 OpenAI/Claude/Gemini API 格式，让任何兼容的客户端都能使用 DeepSeek 的能力。

Obsidian标签问题解决方案

Wed, 10 Jun 2026 00:00:00 GMT

Obsidian 标签问题解决方案#

问题描述#

在使用 Obsidian 查看小万工作间目录下的文档时，发现两类问题：

十六进制颜色代码（如 #3B82F6、#2563EB）被 Obsidian 误识别为标签
小红书笔记自带的标签（如 #互联网大厂 #agent）被 Obsidian 误识别为标签

问题表现#

Obsidian 标签统计中出现大量十六进制颜色代码标签
Obsidian 标签统计中出现大量小红书笔记标签
标签数量统计异常：如 3B82F6 出现 10 次、2563EB 出现 10 次等
影响标签分类和管理体验

问题根源#

Obsidian 会将 Markdown 文档中所有以 # 开头的内容识别为标签，包括：

表格中的颜色代码
代码块中的配置值
普通文本中的颜色描述
小红书笔记自带的标签列表

解决方案#

方案一：批量修复脚本（推荐）#

创建 Python 脚本自动修复所有 Markdown 文件中的颜色代码问题。

脚本功能#

自动扫描所有 .md 文件
识别十六进制颜色代码（3、4、6 或 8 位）
将未被反引号包裹的颜色代码用反引号包裹
避免重复包裹已处理的代码

修复示例#

修复前：#3B82F6
修复后：`#3B82F6`

方案二：小红书笔记标签修复#

针对小红书笔记自带的标签格式，采用以下修复方法：

修复格式#

将 **标签[[**：#互联网大厂 #agent #后端开发 #大厂 #程序员 #面试求职 #大模型 #春招 #校招 #java]] 格式修改为：

1
**标签**：互联网大厂、agent、后端开发、大厂、程序员、面试求职、大模型、春招、校招、java

修复原则#

去掉 # 号，避免被 Obsidian 识别为标签
用顿号（、）分隔标签，保持可读性
保留标签信息，只是改变显示格式

方案三：手动修复#

在文档中手动将颜色代码用反引号包裹：

正确写法：`#3B82F6`
错误写法：#3B82F6

方案四：Obsidian 设置调整#

虽然 Obsidian 本身没有直接排除颜色代码标签的设置，但可以通过以下方式优化：

使用标签过滤插件
手动隐藏不需要的标签
在文档中统一使用反引号包裹颜色代码

修复效果#

修复统计#

扫描文件：339 个 Markdown 文件
修复文件：20 个文件（颜色代码修复）+ 2 个文件（小红书标签修复）
修复内容：
1. 所有未被反引号包裹的十六进制颜色代码
2. 小红书笔记自带的标签格式

修复文件列表#

颜色代码修复#

主要修复了 项目库/guanlan-sina-main/ 下的文档，包括：

LOGO-THEME-UPDATE.md - 前端组件主题更新文档
YikongLogo-README.md - LOGO 组件说明文档
part1_optimization.py - 天筹算法设计文档
项目结构信息.md - 项目目录结构说明
其他配置和文档文件

小红书标签修复#

修复了 面经库/ 下的小红书笔记文档：

10-滴滴AI全栈开发一面.md - 滴滴面试文档
11-Agent八股-记忆检索RAG.md - RAG 八股文文档

预防措施#

文档编写规范#

颜色代码使用规范：在 Markdown 文档中使用颜色代码时，始终用反引号包裹
代码块规范：在代码块中使用颜色代码时，确保正确格式化
文档审核：定期检查文档中的颜色代码格式

自动化检查#

可以创建预提交钩子或文档检查脚本，自动检测未正确格式化的颜色代码。

技术细节#

正则表达式匹配#

1
# 匹配十六进制颜色代码的正则表达式
2
color_pattern = r'#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{4}|[0-9A-Fa-f]{6}|[0-9A-Fa-f]{8})\b'

替换逻辑#

1
def replace_color(match):
2
    full_match = match.group(0)
3
    start = match.start()
4
    end = match.end()
5

6
    # 检查前面是否有反引号
7
    if start > 0 and content[start-1] == '`':
8
        return full_match
9

10
    # 检查后面是否有反引号
11
    if end < len(content) and content[end] == '`':
12
        return full_match
13

14
    # 如果不在代码块内，则用反引号包裹
15
    return f'`{full_match}`'

Show moreShow less

总结#

通过批量修复脚本和手动修复，成功解决了 Obsidian 中两类标签误识别问题：

十六进制颜色代码被误识别为标签
小红书笔记自带的标签被误识别为标签

修复后，标签统计将只包含真正的标签，提高了 Obsidian 的使用体验。

预防措施总结#

颜色代码：在 Markdown 文档中使用颜色代码时，始终用反引号包裹
小红书标签：将 **标签[[**：#标签1 #标签2]] 格式改为 **标签**：标签1、标签2
文档审核：定期检查文档中的标签格式，确保不会被 Obsidian 误识别

建议在以后的文档编写中，始终遵循这些规范，避免类似问题再次发生。

Qoder cn proxy 部署指南

Wed, 10 Jun 2026 00:00:00 GMT

qoder-cn-proxy 部署指南适用场景在 Android 手机上用 Alpine Linux 运行 qoder-cn-proxy，把手机变成 Qoder CN API 的本地代理，供手机 App、浏览器或 OpenAI 兼容客户端使用。前置要求•Node.js v18+（推荐 v22）•Qoder CN CLI：npm install -g @qoder-ai/qoder-cli-cn•Qoder CN PAT Token：从 https://qoder.cn/settings/tokens 获取部署步骤1. 克隆项目cd /workspace git clone https://github.com/avaritiachaos/qoder-cn-proxy.git cd qoder-cn-proxy2. 配置 Tokencp .env.example .env编辑 .env，填入 PAT：QODER_CN_PAT=你的PAT3. 安装依赖npm install —silent4. 启动服务cd /workspace/qoder-cn-proxy export PATH=“/root/.npm-global/bin:$PATH” node clean/server.js默认监听 http://0.0.0.0:3000，启动后输出：Qoder CN clean proxy listening on http://0.0.0.0:30005. 保活用持久化终端会话运行，或放后台：nohup node clean/server.js > /workspace/qoder-cn-proxy/proxy.log 2>&1 &客户端使用配置项值API Base URLhttp://手机局域网IP:3000（如 http://192.168.10.251:3000）API Key任意值或留空Modelqoder-cn、auto、qwen3.7-max、deepseek-v4 等可用端点方法路径说明GET/服务状态GET/health健康检查GET/v1/models列出模型POST/v1/chat/completionsOpenAI 聊天补全（支持流式）POST/v1/messagesAnthropic 消息格式测试验证# 服务状态 curl http://127.0.0.1:3000/ → {“ok”,“name”:“qoder-cn-proxy”,“mode”:“clean”}

聊天补全 curl http://127.0.0.1:3000/v1/chat/completions
-H “Content-Type: application/json”
-d ’{“model”:“auto”,“messages”:[{“role”:“user”,“content”:“你好”}]}‘注意事项•服务监听 0.0.0.0:3000，未配置 HTTPS•首次启动会自动下载 Qoder CN runner（约 200MB），确保网络畅通•Android App 用 http://127.0.0.1:3000 访问，外部设备用局域网 IP

技能列表

Wed, 10 Jun 2026 00:00:00 GMT

小万当前技能列表#

更新时间：2026-06-07

当前保留的 Skills#

bosszhipin
- 功能：BOSS 直聘操作
business-contact-social-links-skill
- 功能：社交账号查找
find-install-skills
- 功能：搜索安装新 skill
google-image-api-skill
- 功能：Google 图片数据提取
google-search-serp
- 功能：Google 搜索结果提取
grill-with-docs
- 功能：文档校验与更新
hatch-pet
- 功能：自定义宠物创建
industry-resume-toolkit
- 功能：简历方法论
interview-q-master
- 功能：输入知识点，输出高频面试题及答案
rednote-skill
- 功能：小红书操作
resume-master
- 功能：HTML → PDF 简历生成
resume-optimizer
- 功能：简历审计与优化
self-improving-agent
- 功能：自我改进循环
skill-creator
- 功能：Skill 创建指导
web-research-assistant
- 功能：AI 网页研究
web-search-scraper-api-skill
- 功能：网页内容抓取
wechat-article-search-api-skill
- 功能：微信公众号文章提取
x-tweet-search
- 功能：X / Twitter 推文搜索
youtube-api-skill
- 功能：YouTube 搜索与视频提取
youtube-video-api-skill
- 功能：YouTube 视频详情提取
zhihu-search-api-skill
- 功能：知乎搜索

已删除的 Skills（本次清理）#

amazon-product-api-skill
amazon-product-search-api-skill
browser-act-skill-forge
social-media-finder-skill
youtube-batch-transcript-extractor-api-skill
youtube-channel-api-skill
youtube-comments-api-skill
youtube-influencer-finder-api-skill
youtube-search-api-skill
youtube-transcript-analysis-api-skill
youtube-transcript-extractor-api-skill
google-maps-api-skill
google-maps-reviews-api-skill
google-maps-search-api-skill
google-news-api-skill
github-project-contributor-finder-api-skill
industry-key-contact-radar-api-skill
linkedin-jobs-search

说明#

本文档保存的是当前精简后的 skill 列表。
后续新增或删除 skill 时，建议同步更新本文件。

抓取linux.do帖子指南

Wed, 10 Jun 2026 00:00:00 GMT

抓取 linux.do（LINUX DO）帖子指南#

适用场景：用户发来 linux.do 帖子链接，要求抓取帖子内容和评论并保存。

背景#

linux.do 是 Discourse 论坛，部署在 Cloudflare 后面。直接用 curl 访问会返回 403，浏览器打开也会卡在 “Just a moment…” 验证页。

Discourse 论坛有内置 JSON API：https://linux.do/t/<topic_id>.json，可以拿到完整帖子数据（HTML、用户名、时间、点赞数等），但 Cloudflare 同样拦截。

核心流程（已验证可行）#

1
1. navigate → linux.do 帖子页面
2
2. set_user_agent → desktop_safari（关键！触发 Cloudflare 自动验证）
3
3. wait_for_selector → #main-outlet（确认验证通过，等 5-15 秒）
4
4. fetch → /t/<topic_id>.json（获取 Discourse API JSON，50-100KB）
5
5. Python 解析 cooked HTML → strip 标签 → 生成 Markdown
6
6. file_write 保存到目标目录

第 1 步：打开帖子页面#

1
browser_use → navigate → https://linux.do/t/topic/<id>/<page>

页面会卡在 Cloudflare “请稍候…” 验证页，这是正常的。

第 2 步：切换桌面 UA（关键步骤）#

1
browser_use → set_user_agent → desktop_safari

这一步是绕过 Cloudflare 的关键。切换 UA 后 Cloudflare 验证会在数秒内自动通过，页面标题变成帖子标题即表示成功。

⚠️ mobile_safari 不行，必须 desktop_safari。

第 3 步：确认验证通过#

1
browser_use → wait_for_selector → #main-outlet（timeout 15000）

如果 found=true 说明验证通过；如果超时，可以截图检查页面状态，或重复步骤 2。

第 4 步：获取 Discourse JSON API 数据#

1
browser_use → fetch → https://linux.do/t/<topic_id>.json

必须用 fetch 动作（不是 navigate，不是 curl，不是 execute_js），因为 fetch 会复用浏览器的 session 和 cookies。

返回的 JSON 包含：

title：帖子标题
views、like_count、posts_count：统计数据
created_at、tags、category_id：元信息
post_stream.posts[]：帖子列表
- username、name：作者
- cooked：帖子 HTML 内容
- created_at：发布时间
- like_count：点赞数
- post_number：楼层号

JSON 文件会自动保存到 workspace 的 offload 目录，工具返回中包含 artifactUri 路径。

第 5 步：Python 解析#

1
import json, html, re
2

3
with open('<artifactUri 路径>') as f:
4
    data = json.load(f)
5

6
posts = data.get('post_stream', {}).get('posts', [])
7
for p in posts:
8
    cooked = p.get('cooked', '')
9
    text = re.sub(r'<[^>]+>', '', cooked)  # strip HTML
10
    text = html.unescape(text).strip()
11
    text = re.sub(r'\s+', ' ', text)  # 合并空白
12
    # text 就是纯文本内容

第 6 步：保存#

用 file_write 生成结构化 Markdown 保存到目标目录。

踩坑记录#

❌ curl 直接请求 → 403#

Terminal window

1
curl "https://linux.do/t/2303618.json" -H "Cookie: cf_clearance=xxx"
2
# 返回 403，即使带了 cf_clearance cookie

原因：Cloudflare 的 cf_clearance cookie 绑定 IP。浏览器的 IP 和 Alpine 终端（proot）的出口 IP 不同，cookie 无法跨 IP 复用。

结论：不要尝试用 curl，必须通过浏览器完成所有请求。

❌ 浏览器内 execute_js → 返回 null#

1
// 这些在 linux.do 页面上都返回 null
2
document.querySelectorAll('.cooked')  // null
3
fetch('/t/2303618.json')  // null

原因：linux.do 页面的 CSP 或 Discourse 框架限制，导致 execute_js 的返回值无法正常序列化。

结论：不用 execute_js 提取内容，用 fetch 动作获取 JSON API 数据再用 Python 解析。

❌ Google 缓存 / Wayback Machine#

Google 缓存：触发 Google 自己的验证，同样不可用
Wayback Machine：抓取的是旧版本，可能不包含最新评论

❌ navigate 到 API URL#

1
browser_use → navigate → https://linux.do/t/2303618.json
2
# 会触发新的 Cloudflare 验证

原因：navigate 会改变当前页面，可能触发新的验证流程。

结论：先 navigate 到帖子页面，通过验证后再用 fetch 请求 API。

分页处理#

默认 JSON API 返回前 20 条帖子
超过 20 条时，用 ?page=1、?page=2 参数获取更多（但实测 21 条帖子只返回了 20 条）
用户链接 /t/topic/2303618/8 中的 /8 表示跳转到第 8 楼，不影响 API 获取

用户链接格式#

格式	含义	topic_id
`linux.do/t/topic/2303618`	帖子首页	2303618
`linux.do/t/topic/2303618/8`	跳转到第 8 楼	2303618
`linux.do/t/topic/2303618/20`	跳转到第 20 楼	2303618

API 请求统一用 https://linux.do/t/2303618.json（去掉 /topic/ 和楼层号）。

完整示例（实际成功案例）#

2026-06-05 抓取帖子 2303618「老哥们新改了一版简历这次有啥大毛病吗」：

577 浏览 · 26 赞 · 21 条回复
JSON 大小 54KB
全部 20 条评论成功提取
保存到 /workspace/小万工作间/L站精华/简历优化建议_L站帖子2303618.md

最后更新：2026-06-05 来源：实际抓取 linux.do 帖子 2303618 的完整过程

文字生成博客插图流程指南

Wed, 10 Jun 2026 00:00:00 GMT

文字生成博客插图流程指南#

这份文档总结了：如何把一段文字整理成适合博客展示的图片，尤其是流程图、结构图、示意图；以及如何避免生成出来的图不好看、空白太多、说明文字过多等问题。

一、适用场景#

这套流程最适合以下内容：

技术流程图
AI Agent 工作流图
系统结构图
文章配图
经验总结图
概念关系图
步骤型教程图

如果你已经有一段文字描述，但没有现成图片，就可以用这套流程把文字变成图。

二、核心思路#

文字生成图片，不是简单“把原文塞给模型”。

更稳定、效果更好的方式是：

先提炼结构
再确定图类型
再确定视觉风格
最后生成图片
生成后再做一轮精修

也就是说，最好的流程不是：

原文 → 直接出图

而是：

原文 → 信息提炼 → 图结构设计 → 风格设计 → 出图 → 二次精修

三、标准工作流#

第一步：明确图片要表达什么#

先问自己一句：

这张图最重要的用途是什么？

常见用途：

帮读者快速理解流程
把长段文字压缩成视觉摘要
给博客增加更直观的插图
展示系统模块之间的关系

如果用途不清楚，图就容易画得又杂又乱。

第二步：把原始文字整理成“图用文案”#

原始文字通常比较长，不适合直接拿来画图。

要先整理成：

标题
主流程 / 主结构
节点顺序
分层信息（可选）
强调点（可选）

示例#

原始文字：

用户消息进入通道适配器，然后经过网关服务器、会话路由器、智能体运行器、模型解析器、系统提示词构建器、历史加载器、会话、任务通道队列、上下文窗口防护机制、大语言模型 API、智能体循环、反馈通路、通道适配器，最终输出文本。

整理后：

标题：OpenClaw 从发送消息到完整反馈的流程
主链路：
1. 用户消息
2. 通道适配器
3. 网关服务器
4. 会话路由器
5. 智能体运行器
6. 模型解析器
7. 系统提示词构建器
8. 历史加载器
9. 会话
10. 任务通道队列
11. 上下文窗口防护机制
12. 大语言模型 API
13. 智能体循环
14. 反馈通路
15. 通道适配器
16. 最终文本

第三步：确定图类型#

不同文字适合不同图。

1. 流程图#

适合：

有明显先后顺序
强调“从 A 到 B 到 C”

例如：

用户请求处理链路
RAG 流程
Agent 工作流
部署步骤

2. 结构图#

适合：

强调模块关系
强调系统分层

例如：

前后端架构
多模块系统关系图

3. 对比图#

适合：

方案 A vs 方案 B
新旧流程对比

4. 脑图 / 分支图#

适合：

一个主题拆成多个要点
经验总结、知识地图

博客里最常用的是：

流程图 + 结构图

四、适合博客的风格选择#

1. 手绘风（Excalidraw 风格）#

最适合博客插图。

特点：

看起来更轻松
比工程图更有阅读感
不容易显得太生硬
很适合 AI、技术、经验总结类文章

适合：

工作流图
系统流程图
教程配图
文章插图

2. 彩色博客插图版#

在手绘风基础上再增加：

轻量配色
模块分组色块
阴影
层次感

优点：

更适合博客正文插图
比纯黑白图更吸引读者
更容易表现“分层”与“分组”

适合：

长文章中的核心示意图
作为文章中的视觉重点

3. 纯工程图风格#

特点：

更严谨
更文档化
更适合系统设计说明

缺点：

放博客里容易显得太硬
没有手绘风亲和

如果是写博客，一般不优先。

五、图片要怎么做得更好看#

这是最关键的部分。

原则 1：视觉上先简后繁#

优先保证：

节点清楚
箭头清楚
顺序清楚
颜色清楚

不要一开始就堆很多装饰。

读者首先要看懂图，不是先被装饰吸引。

原则 2：每个框里的字不要太多#

一个节点最好控制在：

2~8 个字
最多一行半或两行

如果一个框里塞一整句话，图就会显得拥挤。

错误示例：

把长段说明直接放进节点框中

正确方式：

只放核心词
详细解释放正文里写

原则 3：颜色要少而稳#

推荐策略：

白底
黑/深灰线条
3~6 个柔和辅助色

比如：

黄：入口层
蓝：接入层
紫：调度层
绿：上下文层
红：执行层
粉：模型层

不要用太饱和、太刺眼的颜色。

博客图更适合：

低饱和 + 清晰分组

原则 4：箭头一定要明确#

流程图里最容易出问题的是箭头。

需要注意：

起点终点明确
不要交叉太多
尽量让阅读方向一致
行与行之间的连接要自然

推荐阅读方向：

从左到右
或从上到下
如果多行排列，最好用“蛇形流动”并保持清晰

原则 5：标题保留，但说明文字要克制#

适合保留：

一句主标题

不适合过多保留：

“阅读方式引导”
“彩色博客插图版”
“流程总览”
大量注释说明
重复解释型小字

博客插图不是 PPT，不要让图里有太多辅助说明文字。

最好的状态是：

标题 + 流程主体 + 少量必要标签

六、如何避免图片里出现大面积空白#

这是博客插图特别重要的一点。

原因#

大面积空白通常来自：

画布太大
内容排得太散
节点数量不多但用了过宽画布
图已经画完，但没有按内容重新裁边

解决方法#

方法 1：先按内容布局，再决定画布大小#

不要先固定一个很大的画布。

正确顺序：

先算节点范围
再根据节点整体范围加少量边距
最后生成画布尺寸

而不是：

先定一个 2000+ 宽的画布
再把内容放中间

方法 2：边距要“小而够用”#

方法 3：输出前做一次裁紧#

最终输出前，要检查：

最左节点到左边缘的距离
最右节点到右边缘的距离
最下节点到下边缘的距离

如果某一边空白明显大于其他边，就要重新裁紧。

博客图更适合：

紧凑画布 + 统一留白

而不是：

一边空很多，一边很挤

七、如何避免图片里出现过多无关说明文字#

应删掉的内容#

这些通常不应该出现在最终博客图中：

“阅读方式引导”
“彩色博客插图版”
“流程总览”
“这是一个示意图”
“循环执行 / 迭代推理”这类非必要提示
大段解释句

这些说明如果真的需要，应该放在：

图片下方正文
图注
图片前后的文章段落

而不是塞进图里。

该保留什么#

通常保留：

主标题
节点名
必要的分层标签（如果确实有用）

可选保留：

极少量的阶段标签

如果图已经能看懂，就尽量不要加额外文字。

八、一个推荐的出图流程模板#

以后要从文字生成博客插图，可以直接照这个模板走：

输入模板#

1
主题：
2
用途：博客插图 / 流程图 / 结构图
3
风格：Excalidraw 手绘风 / 彩色博客插图版
4
主流程：
5
1. ...
6
2. ...
7
3. ...
8
分层（可选）：
9
- 入口层
10
- 调度层
11
- 执行层
12
要求：
13
- 不要太多说明文字
14
- 不要大面积空白
15
- 适合博客展示

Show moreShow less

输出步骤#

提炼节点
确认节点顺序
确认图类型
确认风格（手绘 / 彩色 / 极简）
生成第一版图
精修：
- 去掉无关说明字
- 压缩空白
- 调整颜色
- 调整节点间距
- 检查在博客里是否协调
最终插入文章

九、博客落地建议#

如果图片最终要放进博客，建议统一这样做：

文件放置位置#

放到文章所属目录或博客静态资源目录，例如：

public/uploads/
或信息库文档同目录

文件命名建议#

尽量：

英文 / 拼音 / 连字符
不要太长
语义清楚

例如：

openclaw-message-flow-tight.svg
rag-workflow-handdrawn.svg
agent-loop-diagram.png

图片引用方式#

Markdown 中：

1
![OpenClaw 流程图](/openclaw-message-flow-tight.svg)

如果是博客站点内的 public/ 目录，也建议统一用绝对路径引用。

十、最终经验总结#

把文字变成博客图片，最重要的不是“让模型乱画”，而是：

1. 先整理结构#

没有结构的文字，出不了好图。

2. 博客图要重可读性#

先让读者看懂，再考虑装饰。

3. 说明文字越少越高级#

图里只保留必须的字。

4. 画布一定要裁紧#

不要让图片一侧出现大片空白。

5. 精修非常重要#

第一版通常只是“能看”，第二版、第三版才是“适合放博客”。

十一、推荐默认规则（可直接复用）#

如果以后没有特别说明，默认按以下规则生成博客插图：

风格：Excalidraw 手绘风
版本：彩色博客插图版
画布：按内容裁紧，避免大面积空白
字数：节点内尽量短
说明文字：只保留主标题，去掉多余说明
配色：低饱和分层色
目标：适合博客插图，而不是 PPT 或海报

十二、一句话版本#

文字生成博客图片的最佳流程是：先提炼结构，再选图类型，再选手绘/彩色风格，生成后重点精修“说明文字”和“画布留白”，最终做成紧凑、清晰、适合博客阅读的插图。