1. 智能体容错控制今天热搜里最该被认真对待的工程话题今天这期日报我先从热搜词的整体风向说起。一眼扫过去Agent 和 LLM 这两个关键词下面热度最高的不再是I 跑了几个 Demo之类的内容而是构建可靠 AI 系统的工程实践AgentPoison 红队攻击AI Agent 怎么扛并发provider rejected the request schema or tool payload这类非常具体的工程和安全问题。换句话说这个领域已经从能不能跑通进入到了跑通之后怎么不崩、怎么防打、怎么扛量的阶段。今天的热搜词里我最想先聊的就是那个有点拗口的LLM 智能体自主容错控制它背后是几乎所有做 Agent 项目的人迟早要面对的一堵墙。1.1 为什么容错突然从论文词汇变成一线刚需先说个现象。很多团队做 Agent 的路径是先用某个框架半小时拼出一个能调用搜索、能读写文件的智能体惊艳全场然后丢到真实环境里跑一周发现故障率轻松超过 30%。工具返回了脏数据、模型把参数拼错了、第三方 API 超时、模型在关键一步想当然了任何一个环节出问题整个任务链就断了。我跟很多做 Agent 的同学聊下来有一个共识LLM 本身的幻觉不可怕可怕的是幻觉没有被兜住顺着工具调用一路放大成业务事故。比如模型在填 SQL 查询参数时把日期格式写错导致查出一堆错误数据再比如模型调用支付类工具时少传了一个字段系统抛异常用户端看到的是流程直接卡死。所以自主容错控制这个词翻译成人话就是让 Agent 在出错的时候自己发现、自己纠正、自己降级而不是把错误原样抛给用户或者直接挂掉。这个需求在单轮对话 Demo 里完全不存在只有把 Agent 放到生产环境的人才会懂疼。1.2 容错的三层结构工具层、状态层、策略层我自己的实践里把 Agent 容错拆成三层来处理每一层职责不同缺一层都会出事。第一层是工具层容错。每个工具调用的入参和出参都要做约束。入参层面不要相信模型生成 JSON 就一定合法需要在进入工具之前用 JSON Schema 做一次校验不符合就直接要求模型重新生成出参层面工具返回的数据是否符合预期格式也需要断言避免脏数据污染后续推理。这部分消耗不大但是能把大量低级错误挡在门外。第二层是状态层容错。一个完整的 Agent 任务往往涉及多次工具调用中间任何一步失败都需要有明确的状态流转。我给任务设计了简单的状态机pending、running、failed、compensated。超时处理放在这一层LLM 调用要有超时工具调用要有超时整个任务要有总超时。重试也要在这一层设计好注意幂等——同一个工具不能因为重试被执行两次尤其涉及写操作、发消息、下单这类副作用明显的动作。第三层是策略层容错。当重试也解决不了问题时要有降级路径。比如主模型挂了降到更便宜的备用模型继续跑完整工具集不可用时收窄到一个受限工具集实在不行把问题转人工队列。策略层是最后一道防线它不追求一定成功而是追求失败得优雅。1.3 可以直接抄的最小容错清单搜热词的人里应该有不少正在写 Agent 代码的我直接给一份按优先级排列的清单你对着逐项检查自己的项目就行。每个工具调用前做参数 schema 校验调用后写结果断言。所有外部调用设置超时LLM 请求设置整体超时并进行指数退避重试。给工具调用加幂等键重试时不产生重复副作用。把失败后的错误信息拼回模型上下文让模型自己反思并修正调用。设置全局失败次数上限超过后切换到兜底回复或人工介入。定期把失败案例导出人工标注后形成错误知识库供后续检索作为模型参考。这套清单我踩坑踩出来的教训总结是容错不是靠某个框架的开关而是靠这些细节叠出来的。很多 Agent 框架提供了现成的 retry 和 timeout 配置但 schema 校验和结果断言通常要靠自己写这一部分别省。2. AgentPoison 之后Agent 安全必须讲清楚的三件事今天搜索词里出现了一篇论文标题AgentPoison: Red-Teaming LLM Agents via Poisoning Memory or Knowledge Base。这个热度过两天可能会降但我觉得值得专门占用一个章节因为它是 Agent 安全里非常有代表性的一类攻击不碰模型权重不碰系统提示词专挑记忆和知识库下手。2.1 攻击链路毒化记忆比越狱提示词更隐蔽AgentPoison 的核心思路可以这么理解现代 Agent 普遍会从长期记忆或外部知识库也就是 RAG 那套检索系统里取信息来辅助决策。攻击者往这些数据源里注入经过特殊构造的文本片段这些片段平时看着无害但只要检索命中就会激活一个事先埋好的触发信号把 Agent 的回答方向带向攻击者想要的方向甚至在后续工具调用中诱导 Agent 执行危险操作。相比直接写提示词去越狱这种攻击隐蔽得多。越狱提示词会被安全策略拦截但知识库里的投毒文本混在海量正常文档中预处理阶段很难筛出来。而且它不依赖和用户的直接交互只要受害者检索到了污染内容攻击就完成了。2.2 从论文到现实RAG、长期记忆与第三方知识源这个攻击离我们有多近放心不是论文里才有的花活。但凡是做了下面这几件事的 Agent都在攻击面内企业知识库问答机器人接入了员工上传的文档、工单、Wiki这些内容本身可能被恶意构造过。个人助理 Agent具备长期记忆能从历史对话里检索信息。如果记忆里被注入了误导性指令后续决策会持续受影响。接入了第三方数据源的 Agent比如新闻、评论、市场数据这些外部来源无法完全可信。尤其要提醒一点很多团队把 RAG 当成天然的防幻觉隔离墙觉得模型只会根据检索内容回答所以是安全的。AgentPoison 恰恰告诉你检索到的内容本身可能就是敌人。这堵隔离墙不仅挡不住攻击还变成了攻击者的投递通道。2.3 工程防御把高危动作关进笼子防御角度我有几条实际可执行的建议不是让你去研究对抗攻击论文而是从工程上降低被打击后的损失。第一分级对待检索内容。从不可信来源检索到的内容只能作为参考性上下文不能让其中包含的指令类文本直接触达 Agent 执行规划层。检索结果里如果出现了明显的你应该你必须请执行这类指令性表达要么过滤掉要么在传给模型前明确标注为用户内容而非系统指令。第二高危动作加确认环节。凡是涉及发消息、转账、删数据、对外 API 调用这类高副作用工具在 Agent 执行前增加一道独立校验。校验可以用规则比如目标地址白名单也可以用另一个模型对工具参数做二次审查甚至落到人工确认。成本不大效果立竿见影。第三定期审计记忆和知识库。长期记忆需要支持查看、删除、清理要能回答我的 Agent 记住过什么。知识库方面建立来源登记对不同来源设置不同的信任等级。最后给个观点Agent 安全的本质不是对抗模型被越狱而是对抗输入数据被污染。在 RAG 架构下数据安全就是 Agent 安全的半壁江山这句话建议你写进团队的安全评审清单里。3. Agent 学习路线与框架选型热搜里的问题一次说透agent开发学习路线agent框架agent框架与编排spring ai agentadk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent——今天这类热词非常集中显然有一批人正处于入局和选型阶段。我按自己的经验把路线和选型逻辑都梳理一遍。3.1 框架分类与选型逻辑别上来就选最重的市面上的 Agent 框架大致分三类先搞清楚自己在哪一类再做选择。第一类是编排型框架代表是 LangGraph、Google 的 Agent Development KitADK这类。它们擅长把复杂任务画成图支持状态管理、条件路由、循环、多人协作适合任务链路长、分支多的场景。ADK 能有 Kotlin/JVM 快速上手教程说明它现在对后端生态覆盖很广Java 技术栈的团队可以直接跑通一个定制的 Agent。第二类是轻量 SDK 型。Spring AI 就是典型它的优势在 Java 生态企业里已经有 Spring Boot 服务加个库就能让现有服务具备 Agent 能力。这类方案不追求编排的灵活性追求的是融入现有后端体系的速度。第三类是自研型。如果你不想被框架约束只依赖模型原生的 function calling再自己写一个 ReAct 循环也完全可以。实际上很多生产级 Agent 最终都走向了少依赖框架、多自研关键链路因为框架解决的通用问题和你的特定业务之间总有一层胶水要自己写。选型我给个朴素建议团队是 Java 技术栈就优先看 Spring AI / ADK 这类和现有体系贴合度高的任务流程复杂、需要可视化设计就选编排型如果只是做一个工具型助手自研函数调用循环最灵活后期也好维护。3.2 四阶段学习路线别急着上框架针对还在问agent开发学习路线的人我直接给一条我自己验证过的路径。第一阶段吃透 function calling。搞清楚模型是怎么通过工具描述来决定调用哪个工具、怎么生成参数 JSON 的。这个阶段不要碰任何框架用原生 API 跑通请帮我查天气的完整链路。第二阶段手写一个最小 ReAct 循环。用几十行代码实现思考-调用-观察-再思考把中间过程打印出来你会对 Agent 的运行机制建立直觉。第三阶段加入记忆和检索。把对话历史、向量库、工具结果缓存接进来理解 Agent 如何在长任务中保持上下文。第四阶段才回到框架。当你手写代码足够多再去看 LangGraph 或 ADK 的编排能力时你会立刻明白它解决了你自己的哪些痛点而不是照着文档瞎用。这个路线反过来走的人特别多一上来就拽一个重型框架最后出了问题根本定位不了是框架的 bug 还是自己配置错了。3.3 并发承载AI Agent 扛并发瓶颈通常不在模型ai agent 怎么扛并发这个热搜词说明很多人开始从原型往生产推了。我的经验是Agent 服务的并发瓶颈往往不在 LLM 推理而在工具调用外呼那一层。一个普通 Agent 请求模型响应可能就一两秒但中间它可能调了搜索、调了数据库、调了第三方 API这些外呼的耗时和失败率才是并发上量的主要障碍。所以思路应该是模型调用用异步并发但每个工具调用要做好超时和连接池管理长耗时任务不要同步等待改用任务队列加 worker 消费任务状态持久化用户侧轮询拿结果同一个上游服务的调用要做限流和熔断避免下游被拖死之后连环雪崩。另外要注意速率限制。很多模型 API 是有每分钟调用数限制的Agent 内部多次工具调用意味着单次会话可能消耗多个请求配额设计并发上限时必须把单个 Agent 任务的请求放大系数算进去否则压测时模型的雷先爆。4. 工具链巡礼Hermes、Rust、Codex、GGUF 与本地化浪潮今天搜索词里工具类的比重很大hermes agent obsidianhermes agent 安装基于rust语言ai agentwelcome to codex, openais command-line coding agent安卓本地运行gguf格式llmspatial llmagent anywhere。我把这些串起来看一个信号很明显Agent 正在从云端 API 的单一形态扩散到个人工作台、命令行工具、移动设备、空间计算等无数角落。4.1 Hermes Agent 与 Obsidian 知识库工作台Hermes Agent 是被好几个热词同时提到的项目它本质上是一个面向开发者和项目管理的 RAG 辅助 Agent核心价值是让工作沟通、项目文档、任务管理都变成可检索的上下文。它真正引起我注意的是 Obsidian 插件这条线——把 Agent 装进个人知识库意味着你的笔记不再是静态存档而是可以被 Agent 主动检索、汇总、关联的动态资料源。如果你打算在自己的知识管理工作流里接 Agent安装这类项目时我提醒几件事一是确认插件来源和权限这类工具需要读取你的本地笔记内容尽量选开源、活跃的项目二是第三方工作台的集成比如聊天客户端、任务工具要单独验证数据流向别让 Agent 在多个工作台之间来回写数据容易把状态搞乱三是给 Agent 划定可访问的笔记范围不是所有 vault 内容都适合交给模型。4.2 Rust 系 Agent为什么有人非要用 Rust 写智能体基于rust语言ai agent这个热词背后是一批对性能和资源占用有要求的开发者。Rust 写 Agent 的优势很明确编译成单二进制、启动快、内存占用小、并发安全。对于需要跑在边缘设备、嵌入式环境或者作为高并发网关前面的一层 Agent 服务Rust 是很好的选择。但我要说句实在话Rust 的 Agent 生态比起 Python 差距明显。Python 那边有海量的工具集成、向量库驱动、评测脚手架很多能力直接用 pip 装Rust 里不少链路得自己造轮子或者依赖数量有限的跨语言绑定。所以我的建议是只有当你已经确定性能或部署形态是硬约束时比如跑在小型 Linux 设备上、嵌入移动端再选 Rust。如果只是为了高级感去折腾性价比不高。4.3 Codex命令行里的仓库级编码 AgentOpenAI 的 Codex 命令行编码 Agent 是今天另一个热度很高的点评论区很多人都在晒登录终端之后的首次体验。它的最大不同在于工作模式你不只是在 IDE 里接受代码补全建议而是给一个命令行 Agent 布置仓库级任务比如把登录模块的错误处理重构一遍、加单元测试、更新相关文档它会自己读文件、改代码、执行命令、跑测试、汇报结果。这类编码 Agent 在生产里怎么用才不翻车我的经验是三个原则小步提交、范围受限、人工审查。让 Agent 一次只改一个聚焦的任务不要让它一口气重构整个模块通过提示词明确它可以触碰的文件范围它改完的 diff 一定要人审。编码 Agent 的效率提升是真实的但它当前更适合当高效的结对工程师而不是无人监管的自动提交程序。4.4 安卓 8 上本地跑 GGUF本地推理的最后一块拼图安卓本地运行gguf格式llm软件支持安卓8这个热词细节度很高说明真有人在老旧设备上折腾本地模型。GGUF 是 llama.cpp 生态的模型量化格式它的意义在于量化压缩之后模型可以在消费级设备上跑得动。如果你想在安卓上本地跑模型我建议按这个思路操作优先用 llama.cpp 相关的安卓版本应用模型选 Q4_K_M 或 Q5_K_M 这类量级7B 级别模型体积在 4 到 6 GB 之间老设备内存吃紧的话先试 3B 级模型。能用 4 位量化解决的不要盲目追求高精度移动端推理的功耗和发热会让你很难受。还有一个很容易忽略的点安卓 8 意味着系统版本比较老要确认你所用的推理应用的最低 API 级别要求。我在实践中发现很多新版本的本地推理应用直接砍掉了旧系统支持你需要在新功能和设备兼容之间做一个取舍。4.5 Spatial LLM 与 Agent Anywhere下一波形态信号spatial llm和agent anywhere这两个词放在一起看指向的是 Agent 正在从文本世界走向空间世界。Spatial LLM 研究的是如何把空间信息3D 场景、地理坐标、物理布局纳入模型理解让模型不仅能谈文字还能理解东西在哪儿Agent Anywhere 则强调 Agent 无处不在——在 IDE 里、在 Notes 里、在命令行里、在手机上、在机器人里。我的看法是短期内别指望这些方向立刻普及但它们给出了 Agent 演化的方向感一是 Agent 会越来越出现在非聊天形态的入口中二是 Agent 的感知范围会从纯文本扩展到多模态空间。如果你现在做 Agent 项目可以在接口层面预留一下空间信息、传感器数据的接入能力未来迁移的成本会低很多。5. 工程排雷手册schema 报错、记忆、Judge、LLM 单测今天的热搜词里有两条特别生产环境味道的一条是 llm request failed: provider rejected the request schema or tool payload另一条是 agent execution terminated due to error。这俩报错我太熟了每个都够开一次一小时排障会。另外 agent记忆llm as judge基于llm的单元测试使用聊天记录模型精调llm 也一起放这章都属于工程细节。5.1 provider rejected the request schema or tool payload 排查链路刚接触 Agent 的人看到这个报错会懵因为提示信息太抽象了。它大白话翻译过来是你给模型 API 传的工具定义或者模型返回的调用参数不符合服务商规定的格式。这类报错我建议按下面的顺序排查别跳步。第一步看完整报错原文。有些服务商会把具体哪个字段不符写在 detail 里一上来就只看摘要会漏掉关键信息。第二步检查工具描述的 JSON Schema。很多服务商不支持过于复杂的嵌套结构尤其是一个字段同时允许多个类型的 oneOf/anyOf 写法绝大多数情况下会被拒。第三步检查工具参数在模型返回时的合法性。模型返回的参数 JSON 可能带上了 schema 里没有的字段或者把数字类型写成了字符串。这个可以在工具入口处做校验校验失败就重新让模型生成。第四步检查 payload 大小和特殊字符。工具描述写太长、字段说明里塞了大段示例文本都会导致请求超出限额参数值里出现 NaN、Infinity 这类 JSON 标准之外的表达也可能被服务商直接拒绝。我最后加一条经验这个报错最容易出现在同一个工具集同时被多个 Agent 复用的场景里某个 Agent 给它加了几个字段另一个 Agent 还拿旧缓存顶着。工具定义的版本管理值得做改过工具之后一定要在真实请求里验证一遍。5.2 Agent 记忆设计长期记忆、短期记忆与压缩策略agent记忆这词几乎每次日报都会出现问的人多是因为文档里的记忆方案总是过于花哨。我讲一套能落地的分层设计。短期记忆就是对话上下文窗口内能直接看到的内容它的核心问题是窗口装不下。用滚动窗口加摘要压缩解决早期对话定期由模型生成摘要摘要和最近若干轮完整对话一起拼进上下文。要注意摘要生成的频率我一般按对话轮数触发每 10 到 15 轮做一次。长期记忆分为三类向量化的语义记忆用来检索以前提过什么、结构化属性记忆用户偏好、项目配置这种键值对、以及事件型记忆按时间线记录发生过什么。写入长期记忆前要有筛选逻辑别什么都往里存。我常用一个简单办法让模型在每次对话结束时对信息的重要性打分只有达到阈值的才进入长期存储。还有一点容易被忽略记忆系统要支持删除和更新否则一次误存的内容会影响 Agent 几周后的行为。你的记忆接口设计时就要预留 delete 和 update 方法别只做个 vector store 就完事。5.3 LLM as Judge 的实测经验llm as judge被讨论这么多年实际操作中仍然有很多细节容易被忽视。我自己做自动评测时踩过的坑主要有三个。第一是位置偏差。同样的两个答案先出现的那个更容易被裁判模型选中。解决办法是两轮互换顺序评测然后合并结果只认定两轮结论一致的样本。第二是冗长偏好。裁判模型会不自觉给更长的答案打高分哪怕长答案里噪音很多。解决办法是在评判提示词里强行规定优先看正确性不看篇幅甚至限制作答字数。第三是裁判模型自身的能力天花板。用一个弱模型去评判一个强模型的复杂输出结果基本不可信。务实的做法是裁判模型至少不比被测模型弱或者直接用能力领先一级的模型当裁判。我的最终建议是LLM as Judge 适合做大规模初筛不适合做最终结论凡是涉及关键质量评价的场景用规则检查加人工抽检一起补上。纯靠模型打分做发布闸门的方案我目前还没有见到真正稳妥的。5.4 用 LLM 做单元测试能省力但别放弃守门人基于llm的单元测试这热度背后是开发者想省掉写测试用例的重复劳动。这个方向确实有效果给 LLM 一段函数签名、文档字符串和几条输入输出示例让它生成边界测试用例一次能批发出几十个覆盖率提升很快。但我必须泼一盆冷水LLM 生成的测试用例质量参差不齐它可能生成一个看起来合理但实际断言方向错了的用例结果测试通过率很高但那些通过根本不能证明代码正确。更危险的是一厢情愿式的用例——为了让代码通过测试把预期结果写成代码实际输出的值这就完全失去了测试意义。我实践下来的方案是用 LLM 生成用例但用规则验证用例本身。生成之后先跑一轮所有失败的用例必须确认是代码 bug还是用例写错所有通过的用例再加一个变异测试层面的抽查改坏一行代码看测试能不能发现。LLM 当批量生成器可以守门人还得是执行层面的人为审查和覆盖率检查。5.5 用聊天记录微调 LLM 的适用条件使用聊天记录模型精调llm适合什么情况我的判断是三条同时满足才值得做一是有大量真实的、高质量的历史对话数据二是现有 prompt 方案已经撞到了天花板三是你需要的是交互风格/说话方式级别的改变而不是知识量级别的改变。精调的时候有几个坑提醒一下。数据要清洗去掉失败对话、重复内容、个人隐私字段对话格式用 ShareGPT 或 messages 风格都行但历史字段不能乱做数据分层训练集和验证集按会话维度切分不要混着切。最后一定要验证微调之后模型的工具调用能力没有退化——很多微调翻车都翻在这里风格学得像模像样function calling 格式全乱了。6. 热搜词快问快答帮你过滤掉一半噪音最后把今天热搜词里剩下一批零散问题快速过一遍。这些问题单独写文章不值当但不回答又确实挡了不少人的路。6.1 Harness 和 Agent 的区别简单说Agent 是干活的主体——它有模型、有上下文、有工具集Harness 是装 Agent 的壳——负责启动 Agent、守护进程、注入信号、收集日志、处理输入输出、定义安全边界。你可以把它理解成发动机和发动机舱的关系。今天能同时看到 llm framework 和 harness 这两个词说明大家开始区分智能体本身和运行智能体的环境了。设计 Agent 系统时把业务逻辑放进 Agent把生命周期管理和安全策略放进 Harness职责清晰后面好维护一万倍。6.2 Agent Skill 到底是什么今天有一篇深度文章叫 Claude Agent Skills: A First Principles Deep Dive 热度不低还有一个相关的 agent skill教程 热搜词。Agent Skill技能本质上是把一段可执行的能力封装成独立单元让 Agent 在需要时动态加载调用。它跟普通工具Tool的区别在于Tool 是预先定义好、静态挂载的Skill 则更接近可发现、可安装、可组合的能力包——Agent 可以在运行中根据任务决定要不要加载某个技能技能的描述和调用方式本身就带着上下文信息。Claude 官方的 Skills 机制是把脚本和资源放在一个目录里通过配置让模型知道技能的存在然后模型判断任务需要时就会去调用对应脚本。这跟大脑需要查资料就翻工具书是一个道理按需加载而不是把全世界的工具都攥在手里。6.3 Pi Agent、Personal Agent 与轻量个人助理pi agent 这类词我判断更可能是某种轻量个人助理项目的名字类似 personal agent 的缩写——它指向的是最近很热的个人助理类 Agent 形态。如果你正打算做这类项目我最想提醒的不是模型选型而是数据权限设计个人助理意味着它能访问日历、通讯录、聊天记录这些数据的读取一定要有独立授权开关而且要能一键清空。个人 Agent 打得过打不过别的产品不好说隐私边界做不好一定死得很快。6.4 Agent Ransack 与Agent 画图顺便澄清一个容易踩的坑Agent Ransack 其实是一个诞生很久的本地文件搜索工具名字里带 Agent 但它和 LLM/人工智能 Agent 没有任何关系别被名字误导去买课或者查教程了。至于 agent画图这说的是 Agent 结合绘图工具的能力。现在主流的做法是 Agent 负责理解用户意图、生成绘图参数再调用绘图 API 或者本地图像模型出图也可以让 Agent 调度多轮修改实现对话式作图。如果你要做这个方向关键不是模型画得多好而是怎么把用户意图到绘图 prompt 的转换做得准这比盲目换更强的图像模型管用。6.5 Agent execution terminated due to error 这类报错怎么处理这行字出现在 Agent 日志结尾时意味着整个 Agent 执行循环因未捕获异常被终止了。处理思路其实在上面容错章节已经说透这里补一个具体的排查顺序先看终止前最后一步是在做什么操作是模型调用还是工具执行然后看是否有超时把执行线程杀掉了再看有没有前置条件不满足就走到了异常分支的情况。这类报错最怕的是只能复现不能定位所以从一开始就要给 Agent 的执行轨迹加上逐步日志每一轮思考、每个工具调用入口都把上下文的关键信息打出来。没有轨迹日志的 Agent 排障等于盲人摸象。以我的经验把执行轨迹完整打印出来的 Agent 项目故障排查效率至少翻一倍。今天日报里的大多数话题从容错控制到安全攻击再到框架选型最后落到执行层面都是同一件事把每一步发生的事情看清楚、可恢复、可审核。这个原则贯穿 Agent 工程化的始终什么时候都不过时。