本章从哪来:示例系统 开发实录
本章是作者开发 AI Agent 桌面应用 示例系统 的经验总结:约 50 万行代码、132 个工具、8 大模块与本章 8 个小节一一对应
本页解决的问题
先给结论「本章从哪来:示例系统 开发实录」要解决的关键问题是什么?
本章是作者开发 AI Agent 桌面应用 示例系统 的经验总结:约 50 万行代码、132 个工具、8 大模块与本章 8 个小节一一对应
让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。
写下一个问题:试完这个方法后,你能用什么证据回答它?
结论听起来很完整,却没有检查最关键的假设。
Electron + React + TypeScript
按需注入,不全塞
三协议适配 + 统一路由
与本章小节一一对应
「用数字认识 示例系统」为什么能找到相关内容
「本章是作者开发 AI Agent 桌面应用 示例系统 的经验总结:约 50 万行代码、132 个工具、8 大模块与本章 8 个小节一一对应」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案,召回之后还要核对
在「本章是作者开发 AI Agent 桌面应用 示例系统 的经验总结:约 50 万行代码、132 个工具、8 大模块与本章 8 个小节一一对应」对应的流程里,Embedding 负责把对象放到可比较的语义空间,近邻索引负责减少搜索范围,最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适,以及内容有没有过期。
先区分找得到和找得准
把「本章是作者开发 AI Agent 桌面应用 示例系统 的经验总结:约 50 万行代码、132 个工具、8 大模块与本章 8 个小节一一对应」落成一次小测试:准备几条有明确答案的查询,记录召回的相关性、遗漏和无关结果,再决定是否需要换切分方式、索引或重排。
从「用数字认识 示例系统」走到「本章 8 个小节 = 示例系统 的 8 个真实模块」
「用数字认识 示例系统」先把问题落在「~500,000 行代码规模 Electron + React + TypeScript 132 个内置工具 按需注入,不全塞 10+ 家模型供应商接入 三协议适配 + 统一路由 8 大工程模块 与本章小节一一对应」上;到了「本章 8 个小节 = 示例系统 的 8 个真实模块」,讨论继续推进到「🎨 AI 生图 示例系统 的形象要靠生图保持一致—— 多模型降级链 + 垫图锚定角色 ,模型挂了自动切换,用户无感 🔄 Agent Loop 主循环配了 防卡死机制 :流失败四级恢复(限流退避 → 换模型 → 断点续传 → 可区分报错)、工具失败熔断、会话防重复派单 🗜️ 上下文管理 五层压缩流水线 :裁剪 → 掐除旧结果 → 微压缩 → 折叠 → 自动全量压缩,用户的原话最后才动 🧠 长期记忆 「见面就记住…」。两段连起来,重点就不只是记住一个结论,而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看:先确定什么算相关,再观察召回是否覆盖问题,最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「用数字认识 示例系统」:~500,000 行代码规模 Electron + React + TypeScript 132 个内置工具 按需注入,不全塞 10+ 家模型供应商接入 三协议适配 + 统一路由 8 大工程模块 与本章小节一一对应
- 「本章 8 个小节 = 示例系统 的 8 个真实模块」:🎨 AI 生图 示例系统 的形象要靠生图保持一致—— 多模型降级链 + 垫图锚定角色 ,模型挂了自动切换,用户无感 🔄 Agent Loop 主循环配了 防卡死机制 :流失败四级恢复(限流退避 → 换模型 → 断点续传 → 可区分报错)、工具失败熔断、会话防重复派单 🗜️ 上下文管理 五层压缩流水线 :裁剪 → 掐除旧结果 → 微压缩 → 折叠 → 自动全量压缩,用户的原话最后才动 🧠 长期记忆 「见面就记住…
- 「这一章你能学到什么」:「调通 API」和「用户能用」之间差了什么? 以生图为例走一遍产品化清单:降级、兜底、一致性、体验,每一项都是 Demo 里看不到的。 Agent 为什么会卡死、跑飞、烧钱? 循环失控的典型模式,以及上限、检测、降级三类防呆设计——产品经理该在哪里画线。 对话越长越贵越笨,怎么办? 上下文压缩的决策框架:什么能删、什么不能删、什么要花钱压;长期记忆怎么筛选、冲突、注入。 Prompt 怎么从一坨文本变成可运营的架构?…
最后的「这一章你能学到什么」把讨论落到「「调通 API」和「用户能用」之间差了什么? 以生图为例走一遍产品化清单:降级、兜底、一致性、体验,每一项都是 Demo 里看不到的。 Agent 为什么会卡死、跑飞、烧钱? 循环失控的典型模式,以及上限、检测、降级三类防呆设计——产品经理该在哪里画线。 对话越长越贵越笨,怎么办? 上下文压缩的决策框架:什么能删、什么不能删、什么要花钱压;长期记忆怎么筛选、冲突、注入。 Prompt 怎么从一坨文本变成可运营的架构?…」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。
读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。
还没有这篇文章的讨论。