今天这份 Agent / LLM 技术精选日报·2026-09-28（知乎版）里，高频出现的词已经从“Agent是什么”慢慢变成“我的Agent在生产环境里挂了”。这其实是个特别好的信号：大家开始不满足于跑通一个demo，而是会在真实业务里纠结可靠性、并发、安全和评测。我按今天的热度数据和个人经验，把智能体自主容错控制、AgentPoison 攻击、LLM as Judge、框架与编排差异、安卓本地 GGUF 部署、还有学习路线这几个方向单独挑出来展开聊。这份日报更适合正在做 Agent 落地、准备给团队做技术选型、或者刚入门想搞清楚该往哪使劲的人，我会尽量把每个话题都拆到可以直接拿去复用的程度。
1. 今天日报里最值得展开的六个方向
1.1 先看总览：今日精选主题速览
我先给一张今天日报的筛选总表，下面再逐条展开。凭标题判断值不值得点进去，其实是有方法的：就看它在回答“怎么做”还是“是什么”，后者可以直接略过。
| 方向 | 关键热词 | 一句话总结 |
|---|---|---|
| 智能体自主容错控制 | Agent、可靠AI系统 | 从检测、恢复、降级、审计四个层面让Agent不挂、能自救、可复盘 |
| 记忆与知识库安全 | AgentPoison、Red-teaming | 攻击者可以往Agent记忆里埋雷，触发词出现时劫持行为 |
| 可信评测 | LLM as Judge | 用大模型评大模型，最大的坑是系统性偏好，不是随机误差 |
| 框架与编排 | Harness、ADK、Spring AI Agent | Agent是决策主体，Harness是运行环境，编排管的是多个Agent的协作 |
| 移动端本地推理 | 安卓8、GGUF | 旧手机也能离线跑量化模型，但内存和Context长度必须精打细算 |
| 学习路线与生态 | Agent Skill、Codex CLI、Hermes | 入门路线要短平快，别一上来就背框架 |
1.2 热词背后：Agent开发正在进入工程化阶段
把今天的热搜词排在一起看，能明显感觉到阶段变化。“agent开发教程”“agent学习路线”“agent框架”还是入门需求，但“ai agent 怎么扛并发”“agent execution terminated due to error”“provider rejected the request schema or tool payload”已经开始涉及生产环境。
这说明什么？说明第一批Agent应用已经进入联调和灰度阶段，大家真正卡住的地方不再是“模型能不能理解指令”，而是“Agent跑起来之后能不能稳定”。这个话题比调prompt更底层，也更值钱。
1.3 我的日报筛选标准
今天为什么单独挑这六个方向？因为它们具备两个共性：一是可迁移，不绑定某个具体产品；二是可落地，看完能直接改自己项目。像“agent画图”“agent ransack”这类工具向的热词，我一般只在生态盘点里带一句，不会花大篇幅写，因为换个工具就失效了。
2. 智能体自主容错控制：构建可靠AI系统的工程实践
2.1 自主Agent为什么比传统程序更容易出故障
传统程序的故障模型是“入参确定、逻辑确定、异常可枚举”。Agent把这三个前提全打破了：模型输出是概率性的，工具返回是外部不可控的，多步推理还会让错误累积放大。
我用一个类比来理解：普通程序像老式手动挡，每一步都是司机主动操作；Agent更像自动驾驶，你只能设定目标和约束，中间每一个传感器、每一次转向决策都可能出错，而且错一步后面全偏。所以容错不是“try catch一下”就能解决，而是要在整个决策链路上布防。
2.2 容错控制的四个层次：检测、恢复、降级、审计
2.2.1 检测层：尽早发现状态异常
检测层要做三件事：结构化日志、输出校验、语义守门。
结构化日志是老生常谈，但我强调一点：每次LLM调用和工具调用都必须有trace_id关联，否则后面排查多步Agent问题时根本无从下手。输出校验指的是对工具返回值做schema校验，很多Agent挂掉不是因为模型错，而是工具返回的数据结构变了，代码直接抛异常。语义守门则是加一道防线，比如模型输出里出现“删除”“转账”“执行命令”这类高风险动作词时，直接拦截进入人工确认。
2.2.2 恢复与降级：不要只依赖重试
重试要分场景。网络超时和限流值得重试，但模型返回格式不对或者工具校验失败，重试十次也没用。我见过不少项目给所有调用套同一个重试装饰器，结果工具逻辑bug被放大了三倍，最后把账号限流打满。
降级策略同样重要。比如Agent的核心工具是天气查询，它挂了能不能先用缓存数据回答？能不能引导用户去网页查？好的降级不是“报错退出”，而是让Agent在能力缩水的情况下仍然完成部分目标。熔断机制也建议加上，连续失败超过阈值就切备用模型或者直接转人工。
2.2.3 审计层：要能重放一整个会话
Agent排查最难的地方在于：同样的输入，下一次输出可能不同。所以不光要记录日志，还要把每个会话的完整上下文、每一步的工具参数、模型中间推理全部保存下来。
我推荐用事件溯源的方式存会话：把每次LLM请求、工具返回、状态变更都当成事件追加写入，然后支持一键重放。这样遇到问题不是猜，而是直接把那次会话拉出来看是第几步偏的。
2.3 可以直接抄的容错代码骨架
下面这段代码是我项目里一直在用的最小容错骨架，核心只有三件事：重试策略、熔断开关、工具超时。
import time import random from dataclasses import dataclass @dataclass class CircuitBreaker: failure_threshold: int = 5 recovery_timeout: int = 30 _failures: int = 0 _opened_at: float = 0 def allow(self) -> bool: if self._failures >= self.failure_threshold: if time.time() - self._opened_at > self.recovery_timeout: self._failures = 0 return True return False return True def record_failure(self): self._failures += 1 if self._failures == self.failure_threshold: self._opened_at = time.time() def call_llm_with_retry(client, messages, tools, max_retries=3): breaker = CircuitBreaker() for attempt in range(max_retries): if not breaker.allow(): raise RuntimeError("circuit breaker open, falling back to backup model") try: # 单次工具调用超时要小于总超时，建议 15s/30s/60s 分级 return client.chat.completions.create( model="your-model", messages=messages, tools=tools, timeout=30 ) except (TimeoutError, ConnectionError): wait = min(2 ** attempt + random.random(), 8) time.sleep(wait) except Exception as e: # 认证错误、参数错误这类问题不需要重试 if "authentication" in str(e).lower() or "invalid_request" in str(e).lower(): raise breaker.record_failure() time.sleep(1) raise RuntimeError("llm call failed after retries")里面有一个很关键的设计：不是所有异常都重试。认证错误、请求格式错误这类确定性失败，重试只会浪费时间。只有网络类、限流类、超时类错误才值得用指数退避。
2.4 我踩过的三个最坑的容错场景
第一个坑是模型返回的tool_call参数里嵌套了JSON字符串，直接json.loads会失败。我的解决办法是先做一次“剥壳”：把代码块标记和转义处理掉再解析，仍然失败就强制要求模型重新生成一次参数。
第二个坑是整体超时设置了，但单步工具没设。结果一个外部接口卡了五分钟，整个Agent任务被拖死，Trace里还看不出是哪一步卡住。现在我的原则是：LLM调用有超时，工具调用有超时，整轮循环也有超时，三层缺一不可。
第三个坑是双Agent互相讨论不收敛。两个模型互相给结论，能聊几十轮。后来我加了两个硬性约束：最大轮数上限，以及“如果最近三轮内容相似度超过阈值，自动终止并输出当前结论”。这两个约束至今没删掉。
3. 记忆投毒与可信评测：今天安全方向的硬话题
3.1 AgentPoison：往记忆和知识库里埋雷
AgentPoison 属于红队攻击研究，核心思路是在Agent的长期记忆或知识库里植入恶意样本。攻击者不会直接把恶意内容写得很明显，而是把样本包装成和日常问题高度相似的“无害内容”，让向量检索在用户提问时把它召回来。召回之后，Agent会把它当成高可信上下文，进而按照攻击者预设的意图输出建议或执行动作。
这条攻击链最麻烦的地方在于：它绕过的是检索，不是生成。传统prompt注入需要在用户输入里做文章，攻击者容易被发现；但把恶意样本混进记忆库后，用户问一个正常问题，恶意内容靠相似度自己“跳”出来，用户毫无感知。
3.2 实打实的防御思路
防御AgentPoison不能只靠“清洗数据”，因为你很难区分一条记忆是正常的还是故意伪装的。我建议从四个层面做：
第一，来源分层。把记忆按来源打标签：用户明确提供的、系统自动记录的、外部知识库检索的。不同来源赋予不同信任度，外部来源的内容在用于决策前必须经过安全分类。第二，检索后过滤。召回结果先过一次敏感内容分类器，代码执行、凭证访问、文件删除这类高危指令直接拦截。第三，最小权限执行。Agent能力范围内只开放必要的工具，高危操作一律二次确认。第四，周期性红队重放。把已知攻击样本混进测试集，每次更新知识库都跑一遍，确保没有新的触发路径。
3.3 LLM as Judge：效果评测如何不被模型偏好带偏
LLM as Judge 是今天热搜词里非常有价值的一个方向。它的核心是用一个能力强的大模型去评估另一个模型的输出质量。听起来方便，但实际用起来坑不少。
我整理过模型当裁判最常见的四种偏差：自我偏好（模型更喜欢自己生成的答案）、位置偏差（两个候选答案调换顺序后评分不同）、长度偏差（越长越容易被判高分）、语气偏差（更“自信”的答案得分更高）。
实操时我的做法是：先定义非常具体的Rubric，把5分标准写到“出现X行为扣1分，包含Y要素加1分”这种粒度；然后对两个候选答案做A/B、B/A两轮排序，取多数结论；尽量用两个不同厂商的模型交叉评审，降低单模型偏好；最后拿100条样本人工标注，算一下模型裁判和人的一致性。一致率低于80%就说明Rubric还没写清楚，需要调整。
3.4 安全与评测要同步进入迭代
我观察到一个普遍问题：很多团队把评测和安全放到上线前才做，结果上线前半个月才发现Agent在80%场景下输出不稳定。更好的做法是把评测集和红队样本纳入CI，每次改prompt、换模型、更新知识库都自动跑一遍。回归成本高一点，但比上了生产再救火划算得多。
4. Agent框架与编排：明确几个概念再选型
4.1 Agent不是框架，Harness不是Agent
今天好几个人在问Harness和Agent的区别，这是概念最容易混淆的地方。我用自己的理解做个区分：
| 概念 | 职责 | 类比 |
|---|---|---|
| LLM模型 | 文本生成与推理引擎 | 发动机 |
| Agent | 决策循环：观察、推理、行动、消化结果 | 司机 |
| Harness | 运行支撑：模型连接、工具注册、状态管理、安全、日志 | 车身和底盘 |
| 编排 | 多个Agent的启动、通信、任务分配、生命周期 | 车队调度 |
Agent是决策主体，Harness是承载Agent运行的“壳”。你写代码时真正关注的是Agent的决策逻辑，但能不能稳定跑起来，往往取决于Harness够不够健壮——工具注册是否灵活、状态是否可恢复、日志是否完整。选框架时我会先看这四项能力。
4.2 选框架时真正要看的四个能力
第一，状态管理与checkpoint。Agent跑到一半进程重启，能不能从最近的状态恢复？第二，工具注册与schema生成。你定义好的函数能不能自动转成模型可用的tools定义，并且支持复杂嵌套参数？第三，安全与可观测性。有没有内置的trace、审计、权限校验？第四，并发模型。
这里着重说一下并发。今天热搜里有“ai agent 怎么扛并发”，我的建议是：框架本身不解决并发，真正的解法是让Agent无状态化——会话状态存到Redis或数据库，工作进程可以水平扩展，每次请求从存储里重建上下文。框架的并发能力远不如你的架构设计重要。
4.3 Spring AI Agent：JVM生态里最顺手的入口
Spring AI 在Java/Kotlin生态里算是最容易被团队接受的Agent开发方式，因为它的编程模型和Spring Boot完全一致。最简单的接入方法是定义一个工具方法，加上@Tool注解，然后通过ChatClient调用：
@Service public class WeatherTool { @Tool(description = "查询指定城市的实时天气") public String getWeather(String city) { // 实际项目中这里会调用真实天气API return "晴，26摄氏度，适合出行"; } }调用端也很简单：
ChatClient chatClient = ChatClient.builder(chatModel) .defaultTools("getWeather") .build(); String answer = chatClient.prompt("北京今天天气怎么样？适合跑步吗？") .call() .content();注意不同版本的Spring AI API调整比较频繁，具体注解包名以你当前依赖的稳定版文档为准。但核心思路不会变：把函数注册给模型，模型处理多步任务时自己决定调用哪个函数。
4.4 ADK Kotlin：在JVM上跑通最小Agent示例
今天热搜里ADK Kotlin的讨论度不低。ADK的思路和Spring AI略有不同，它把整套东西拆成模型客户端、Agent定义、运行时三个部分。一个最小示例长这样：
val model = GeminiLlmClient(apiKey = System.getenv("GEMINI_API_KEY")) val travelAgent = Agent( name = "travel_agent", instruction = "你是行程助手，回答要简洁，不要编造信息。", model = model ) val app = Application( agents = listOf(travelAgent), runner = Runner() ) fun main() { val response = app.run( agent = "travel_agent", input = "帮我规划明天杭州一日游" ) println(response.contents) }这类框架的API现在还在快速迭代，我建议直接参考官方仓库的示例代码，只看文档经常踩版本坑。但上手路径很清晰：三步走，配置模型、定义Agent、用Runner跑起来。
4.5 框架选型的个人建议
我的选型原则很简单：如果只是单Agent加两三个工具，直接用模型原生的Function Calling加一层薄封装就够了，完全不需要上框架；如果需要多Agent协作、复杂状态流转、人机协同确认，再考虑Spring AI、ADK、LangGraph这类方案。框架最大的隐含成本是绑定，一旦核心逻辑和框架强耦合，后面想换会很痛苦。
5. 本地部署与移动端推理：安卓8上跑GGUF模型
5.1 GGUF到底解决什么问题
GGUF是llama.cpp社区推出的模型容器格式，把权重、超参数、分词器全部打包成一个文件，并支持多种量化级别。好处是单文件部署、内存占用可预期、CPU推理友好。对移动端来说，最大的价值是可以在离线环境跑模型，不依赖网络和云端API。
5.2 安卓8本地推理的实操步骤
先说结论：安卓8（API 26）的老设备上跑本地模型是完全可行的，但千万要控制模型规模。
第一步，确认设备内存。我的经验公式是：手机内存至少要是模型体积的两倍以上。跑一个1.5B的Q4量化模型（约1.1GB），4GB内存的手机比较稳；想跑3B级模型（约2GB），建议6GB内存起步。
第二步，选模型文件。去HuggingFace搜目标模型的GGUF版本，新手优先选Q4_K_M量化：质量损失小，体积适中。Qwen2.5系列的1.5B和3B是移动端非常稳的选择，中文效果好，指令遵循能力也够用。
第三步，选运行App。PocketPal AI这类开源App对老安卓支持比较好，安装前确认minSdkVersion不高于26。llama.cpp的Android版本也可以，但命令行操作对普通人门槛高一些。
第四步，导入模型并设置参数。上下文长度建议先填2048，线程数设为设备大核数量，采样温度0.7。不要一上来就拉高context长度，老设备很容易直接闪退。
5.3 老设备上的速度与体验实测
我用一台骁龙660、4GB内存的旧手机实测过：跑1.5B Q4模型，纯CPU解码速度大概在8到12 token/s，回答“今天天气怎么样”级别的简单问题基本可用，但要等一会。一旦把上下文拉到4096，速度会明显下降，发热也更严重。
这个速度决定了它的使用场景：离线问答、隐私敏感的数据处理、快速原型验证。别指望它在手机上处理长文档总结，效率会让你崩溃。
5.4 踩坑记录：安卓8常翻车的几个点
第一个坑是App要求高版本Android，安装时报“解析包错误”，就是API不兼容，换minSdkVersion更低的App即可。第二个坑是模型文件放错目录，很多App只认自己特定的模型文件夹，建议按App文档里的路径放置。第三个坑是Context开太大导致内存溢出，表现为闪退或系统杀后台。第四个坑是别迷信GGUF在旧设备上有多快，NPU加速在安卓8时代基本不存在，老老实实按CPU性能预估。
6. Agent学习路线与生态工具盘点
6.1 我给新人的四步学习路线
看到热搜里“agent学习路线”“agent开发教程”反复出现，我给一份节奏明确的学习计划，每天两小时，四周能形成一个完整的Agent实战项目。
| 阶段 | 核心任务 | 目标产出 |
|---|---|---|
| 第一周 | 熟悉LLM API和Function Calling | 做出一个会调用查询工具的小Agent |
| 第二周 | 实现会话记忆与上下文压缩 | Agent能多轮对话且不爆token |
| 第三周 | 学习一个框架并做双Agent协作 | 完成一个简单的任务规划Agent |
| 第四周 | 建评测集、加容错控制 | 在模拟故障下Agent能自动恢复 |
我的核心建议是：第一周不要碰任何Agent框架，直接用模型API手写一遍循环——用户输入、模型推理、工具调用、结果回填。这步做完，你对Agent本质的理解会远超那些只背框架的人。
6.2 Agent Skill与可复用技能包
Agent Skill是今天的热词之一，它解决的是“复用”问题。把一组固定的动作封装成技能，包括任务描述、触发条件、执行脚本、输入输出示例，Agent遇到相关任务时自动加载。管理方式上可以简单到就是一个目录加一个README，复杂点可以做技能仓库，按需下发。它的价值在于：写好的技能不用重复具现，新Agent可以直接启用。
6.3 生态工具盘点：Hermes、Codex、Obsidian工作台
Hermes Agent最近热度不低，它是插件式设计的开源Agent，搭配Obsidian可以作为第三方工作台使用，把笔记资料库变成Agent的知识源，适合做个人知识管理场景。Codex CLI则是命令行编程Agent，需要用ChatGPT登录态来鉴权。这背后有个普遍问题值得注意：命令行Agent的权限很大，它修改文件、执行命令都发生在你本地，一定要做好沙箱和操作确认。
另外LLM Studio是桌面端跑本地模型最省事的工具之一，适合Windows机器快速验证模型。Rust生态的Agent项目适合对性能敏感的场景，但学习成本明显更高，不建议新手一上来就选这个方向。
6.4 日报里顺带值得留意的小方向
Spatial LLM在往空间智能方向走，做的是空间理解与3D场景推理，现在处于很早期，但值得关注。基于LLM做单元测试生成，在生成测试用例和断言方面效果不错，但别让它直接跑生产环境。用聊天记录精调LLM也是个值得尝试的方向，不过要注意把历史对话转成指令对的时候清理噪音，否则模型会被带偏。
7. 常见报错排查：两行报错背后的真相
7.1 “provider rejected the request schema or tool payload”怎么查
这条报错今天出现在热搜里，我太熟悉了，第一次遇到时排查了整整一下午。它通常发生在工具调用场景，原因是模型服务商拒绝了你的tools定义或工具返回的数据结构。
按顺序排查：第一步，把实际发给provider的完整请求体保存下来，重点看tools数组。第二步，检查工具函数名是否有非法字符，参数描述是否为空，参数类型有没有用不支持的写法。第三步，逐个禁用工具做二分定位，经常是某一个工具的参数定义带入了非标准字段。第四步，检查工具数量是否超出当前模型限制，工具太多也会触发同样的拒绝。
这里有一个我常踩的细节：模型版本和工具调用不匹配。同一个模型的新旧版本对strict schema的支持不一样，换版本后老代码会突然报错。
7.2 “Agent execution terminated due to error”常见根因
这条报错是最容易误导人的，因为它只告诉你“执行终止了”，不告诉你为什么。我整理过几种常见根因：
| 现象 | 根因 | 优先排查项 |
|---|---|---|
| 某一步工具调用后立刻终止 | 工具内部抛出了未捕获异常 | 给子工具加try/catch |
| 多轮循环后终止 | 超过最大步骤数限制 | 增加max_iterations或加收敛判断 |
| 长时间等待后终止 | 单步调用超时 | 给LLM和工具分别设置超时 |
排查时最重要的是看那一整条会话的trace日志，只看顶层报错永远不知道是哪一步出的问题。
7.3 无效tool_call导致反复重试
还有一种高频问题：模型返回的工具调用参数格式不对，导致解析失败，Agent反复重试打爆API额度。模型偶尔会把参数包在代码块里，或者字段名和定义不一致。我的兜底写法是：解析失败后不直接放弃，而是把错误信息回填给模型，让它“重新生成合法的参数”，这一步通常能救回大部分情况。同时把temperature调低到0.3以下，可以显著减少格式错误。
8. 今天日报之外的三个个人提醒
8.1 先做“会挂”的演练，再做“会思考”的优化
我见过太多团队把精力放在调prompt让Agent“更聪明”上，结果一次外部接口抖动就把全流程打崩。我自己吃过亏之后，现在每次Agent上线前必做故障注入演练：让工具随机超时、让模型返回空值、让知识库查不到数据，看Agent能不能扛住。这个环节比任何花哨的提示词都值得先做。
8.2 记忆是资产也是风险
Agent的记忆和知识库是它比普通程序更强大的原因，也是今天AgentPoison攻击指向的薄弱环节。我在实际项目里的体会是：动手写记忆模块之前，先想清楚哪些内容能写、哪些来源可信、哪些动作需要二次确认。记忆一旦被污染，影响面比单个prompt注入大得多，因为它会持续存在并且被后续所有对话引用。
8.3 日报再多，也不如自己把一个场景跑完
今天日报里值得研究的方向几乎每一个都能展开成一本书。但我还是要说一句：选定一个自己的场景，把它从模型调用、工具注册、记忆处理到容错控制完整跑通一遍，比刷完所有技术文章都管用。这个过程中遇到的那些报错和坑，才是你真正能带走的东西。
