2026-09-27 的 Agent / LLM 技术精选日报来了。先交代一下这份日报的定位：我把社区里零散的热搜词、高赞回答、新发的论文和工程踩坑帖子，按“值得精读”和“值得动手”两类收拢在一起，做成今天这份清单。知乎版的习惯是——评论区问得最多的问题我会多展开两句，只有标题没有正文的“神贴”我会尽量点明它到底在讲什么。

今天的热词板上有两种声音特别明显：一种在问“Agent 是什么、怎么学、怎么从零开始搭”，另一种已经在为生产环境里的并发、工具调用报错和安全性问题头疼。这两种人今天的内容都有覆盖，前者主要放在学习路线部分，后者直接看实战避坑章节。不用从头到尾顺着读，按你自己的当前阶段挑着翻就行。

1. 今日日报的选题逻辑：我为什么盯上这些 Agent/LLM 信号

1.1 日报筛选信息的一般流程

做这类技术日报，最忌讳的是把热搜词复制粘贴一遍就算完事。我的流程分三步：先看热词之间的关联密度，再看讨论里反复出现的“问题句式”，最后判断哪些内容可以沉淀成通用经验。

今天热词的三条主线索其实很清晰：

• 第一类是概念入门向：agent是什么、agent框架、agent学习路线、agent开发教程；
• 第二类是工程落地向：ai agent怎么扛并发、工具调用被provider拒绝、agent执行终止报错；
• 第三类是前沿与安全向：基于LLM的智能体容错控制、AgentPoison投毒攻击、LLM as Judge、Agent安全。

三个方向的读者画像完全不同。第一类人可能是刚转行的开发，或者还没想清楚 Agent 和自己的业务有什么关系；第二类是已经在写生产代码，天天被线上问题追着跑的工程师；第三类相对少一些，但往往是最需要提前做技术储备的一批人。

1.2 热词背后的“隐性信号”比表面意思更重要

举几个例子。今天“harness和agent区别”这个词能排上来，说明很多人在看框架源码时遇到了自定义编排逻辑和现成Agent框架之间的概念混淆。这个点我会专门在第五部分讲清楚。

再看“llm request failed: provider rejected the request schema or tool payload”这条，它本质上不是一个搜索词，而是一个报错信息被原样复制到了搜索框里。能搜出这个错误的人，说明已经被工具调用校验卡了一段时间。这种“带着报错搜索”的词，是工程类日报里价值最高的内容，因为背后站着真实的生产事故。

还有“支持安卓8”“安卓本地运行gguf格式llm软件”这类词，表面上是问怎么在旧手机上跑本地模型，实际上是开源模型+端侧部署需求在升温。虽然今天没有把它列为头条，但这个信号我记下了，后续会持续跟踪端侧推理的性能数据。

1.3 今天我留下的筛选标准

我不是所有热词都会收录。今天有三条判断标准：

• 能讲清原理吗？如果只是工具推荐或新闻转载，不放进“值得精读”；
• 能指导决策吗？比如框架选型、架构取舍、安全加固这些，必须给出判断依据；
• 有没有信息增量？重复别人说过的话没意义，我把讨论中分散的点重新组织，补上背景和边界。

根据这三条标准，今天挑出了六组内容：深度文章精读、工程避坑、工具链上新、学习路线、评估方法、安全实践。下面按顺序展开。

2. 值得通读一遍的深度选题：容错控制、记忆投毒与空间智能

2.1 《LLM智能体自主容错控制》：把可靠性当成整个系统的属性来设计

今天最值得精读的，是一篇讨论“基于LLM的智能体自主容错控制”的工程实践内容。它没有停留在“加个try-except”这种表面功夫，而是把容错当成整个Agent系统的一个横切属性来设计。这个视角我觉得是对的。

Agent系统跟传统微服务有个本质差异：微服务的错误模式相对固定，超时、限流、熔断基本能覆盖大部分情况，但Agent的一个循环里，模型可能因为提示词微调、工具返回格式变化、上下文被截断等原因，产生完全不可预测的中间状态。错误不来自某一行代码，而来自模型输出本身的概率性。

基于这个背景，文章里提到的容错手段，我认为可以归纳成四层：

• 输入层容错：用户在对话中给出的指令通常含糊、多目标，Agent在拆解任务时容易遗漏隐含约束。可靠的系统会在进入执行循环之前，让模型先把用户指令复述一遍并列出约束条件，这一步能过滤掉大量前期误解。
• 执行层容错：工具调用可能返回500、限流、空值、格式不符等各类异常，设计上要给“模型自纠错”留出口。常见做法是检测到工具报错后，把错误信息做结构化清洗再喂回给模型，让它重新规划工具参数，而不是立即终止任务。
• 验证层容错：让模型对执行结果做一次“自检”。比如写代码任务，就让另一个模型实例或者同样的模型使用不同的prompt模板检查生成结果；涉及数值计算的场景，可以再加一段确定性规则校验，比如“结果必须在某个范围内”“数量必须非负”。
• 恢复层容错：当重试超过阈值时，系统需要决定是降级执行部分任务、换一条执行路径，还是直接请求人工介入。这层设计最容易被忽略，但它决定了Agent在无人值守时到底能不能用。

文章里还有一个观点我很认同：所有重试都不能无限进行。每个Agent任务必须有最大步数、最大token数、最大工具调用次数这三道“硬闸门”。没有闸门的系统，理论上会陷入死循环，账单先不说，光是日志噪音就能淹没问题定位的线索。

提示：自主容错控制的第一原则不是“让模型自己修复一切”，而是“定义清楚什么情况下可以修复、什么情况下必须停止”。所谓智能体自主，指的是在可控边界内自主，不是无限自治。

2.2 AgentPoison论文速读：攻击记忆和知识库的红队视角

今天另一篇必须关注的是一个红队方向的成果：AgentPoison，核心思想是给LLM Agent投毒——具体目标是记忆模块和知识库。

这个攻击思路乍一听有点反直觉：知识库里存的都是经过整理的文档，为什么会被投毒？关键在于检索增强生成（RAG）机制本身。当用户向Agent提问时，Agent会先从向量数据库中召回最相关的片段，再拼接到上下文里让模型生成答案。攻击者不需要控制Agent本身，只需要找到“能诱导Agent在回答中引入恶意内容”的文本片段，把它藏在文档里，让检索器在特定问题下把它排到前面。

这类攻击的现实场景很多：企业内部知识库常需要读取外部导入的文档、网页、邮件；天气服务、客服系统通常要实时抓取第三方数据源。如果这些数据源没有可信校验，投毒片段混进去之后，后续所有问答都会被污染。

从工程对抗的角度，我理解有三种缓解思路：

• 检索源隔离：把内部文档和外采数据分库存储，检索时明确标注来源，模型在合成答案时不会被低可信数据带偏；
• 内容强校验：对要写入知识库的文本做双向校验——既检查它是否有隐藏指令，也检查它是否包含与主题无关的“触发器词”；
• 回答门禁：当Agent的回答引用了某个外部来源时，强制附带原文链接或出处，用户能二次确认，模型也更倾向于保守表达。

今天这篇给我最大的启发不是攻击本身的巧妙，而是它证明了“Agent安全”不能只盯着提示词注入，记忆库、工具返回、历史会话都是攻击面。安全设计需要从Agent的外围——数据管道开始做，而不是等上线之后再加WAF。

2.3 Spatial LLM：当模型开始处理“空间”这一基本维度

今天“spatial llm”能出现在热词榜上，说明业内对多模态和空间理解方向的关注度在增加。Spatial LLM，简单说就是让大模型理解空间关系：上下左右、远近高低、坐标、朝向、遮挡关系。

之前大多数人用LLM做的是“语言层面的推理”，比如总结、翻译、代码生成。但空间理解要求模型把文本描述映射到几何结构上。比如“把杯子放在桌子的左上角”，一个普通语言模型也许能讲出这句话的含义，但没法直接引导一个机械臂去执行；Spatial LLM则试图把这种描述转换成一组可计算的坐标或路径规划指令。

这背后的技术路线通常分两类：一类是在视觉-语言模型的基础上，用空间标注数据做微调，让模型学会根据图像输出坐标或深度；另一类是把它作为规划器，输出自然语言路径指令，再由传统机器人控制栈去执行。今天热词里还有“识的llm智能体自主容错控制”，某种程度上强调的也是这种跨“感知—规划—控制”的系统可靠性问题。

我对这块的观察是：Spatial LLM 目前还处在“演示惊艳、工程难落地”的阶段。难点不在模型能力，而在坐标系的统一。不同的传感器、摄像头、雷达输出的坐标系五花八门，模型要能适应不同坐标定义，还得容忍标定误差。真要做这个方向的工程化，得先花大量时间解决数据对齐，而不是直接上大模型。

2.4 另一篇值得保存的入门：Claude Agent Skills的第一性原理分析

今天还有一篇关于Claude Agent Skills的技术长文，标题带着“从第一性原理深入解析”的味道。大多数人对“Skills”这个概念的理解容易跑偏：有人把它等同于插件，有人把它看成提示词模板。但这篇文章更准确的落脚点是——Skills是一套“可复用的操作化指令包”。

和普通的工具调用不同，普通的Tool是一个能被模型调用的函数，输入输出都是结构化的数据；而Skill往往把“任务背景、拆解步骤、注意事项、示例输出”打包在一起，模型在遇到相关任务时，会先读取这份说明，再决定怎么执行。它介于“工具”和“流程文档”之间。

这篇文章里让我觉得有收获的地方，是它区分了“什么时候该用Skill，什么时候不该用”。如果任务是高度确定性的，比如查天气、发邮件，用Tool就够了，没必要把一堆操作说明塞进上下文；只有当任务需要“知道怎么做、按什么顺序做、做了之后要注意什么”时，Skill才有价值。而一旦任务规则开始频繁变化，Skill就需要跟着频繁更新，这时候更值得考虑的是把它固化成程序逻辑，而不是继续依赖自然语言描述。

把这一篇和我前面说的记忆投毒联系起来看，会更有意思：Skill本质上也是Agent记忆的一种形态，它如果被外部数据源污染，危害比普通知识库更大，因为Skill会直接改写Agent的执行策略。这个风险点后续需要专项跟进。

3. 工程现场最热的三个实战问题：并发、工具调用报错与回合终止

3.1 AI Agent怎么扛并发？先回答三个问题再说方案

“ai agent怎么扛并发”今天高频出现，我估摸问这个问题的人已经跑通了单机Demo，正往生产环境迁移。Agent的并发和传统Web服务的并发根本不是一回事，如果照搬“加机器、上负载均衡”的思路，很快会被打脸。

传统Web服务的并发瓶颈在容量：数据库连接池满没满、线程池够不够、带宽有没有到顶。Agent服务的并发瓶颈则是状态与速率：每个会话都持有独立的上下文，LLM接口有TPM/RPM限制，工具的调用结果也要被送到模型再推理一次——链路里的每一个环节都可能成为瓶颈。

我在做的项目里，把并发处理拆成了三层：

• API网关层：做租户维度限流，比如按API Key配额，避免一个激进用户把整体配额打爆；
• 编排层：为每一个会话做独立的速率控制。不是全局排队，而是每个会话单独维护一个令牌桶，防止一个会话瞬间产生几十个工具调用请求；
• 工具层：外部API调用统一走带重试和熔断的代理池，避免因为某个第三方接口抖动而拖垮整个Agent流程。

还有两个容易被忽略的细节。第一，上下文长度直接决定单个请求的延迟和成本，可以通过上下文压缩策略来提升单机可承载的并发数。第二，Agent框架内部通常会串行执行“取工具→调工具→送回模型→再取下一个工具”，这个循环天然限制了单个会话的吞吐，想在单会话内部做并发，得把多个工具调用合并成一条消息批次发给模型，这需要模型版本支持并行工具调用。

提示：扛并发的第一步不是选框架，而是先定义你的并发指标。是并发会话数、每分钟请求数，还是每分钟处理token数？三个指标对应完全不同的优化手段。

3.2 工具调用被拒：“provider rejected the request schema or tool payload”

如果你搜过“llm request failed: provider rejected the request schema or tool payload”，那你大概率已经在用结构化工具调用（function calling），而且被模型服务端的一个校验错误卡住了。

这串报错的意思是：模型服务商在返回响应时，发现你的工具定义或工具调用参数不符合它的校验规则。常见触发原因有三个。

• 第一个原因是工具定义的JSON Schema有问题。最典型的是给参数类型定义错了，比如把字符串枚举写成了数字，或者没有给required字段补齐必填属性。服务端在解析工具定义阶段就会拒绝整个请求。
• 第二个原因是工具调用的实际参数和定义不一致。模型生成的参数有时会多出定义里没有的字段，或者缺了必填字段。尤其是当工具定义用到了“anyOf、oneOf”这类复合类型时，模型很容易生成出不符合约束的JSON结构。
• 第三个原因是模型服务端开启了“严格模式”。严格模式下，所有结构化输出必须严格符合Schema，任何多余空格、字段顺序变化、类型不匹配都会被拒。

我的排查步骤已经固化成了模板。第一步，确认是哪个请求失败，复制原始的模型返回内容，看它是否包含了更内层的错误码，很多框架会把真正原因漏掉，只在最外层给了这串通用文案。第二步，单独把你那个报错的工具定义拿出来，用JSON Schema校验器离线验证一遍，顺便把工具定义清空，只请求模型返回一个测试工具调用，用二分法定位是哪一个工具定义引发问题。第三步，如果在严格模式，看是否能给模型降低温度，或者换一个更宽松的采样参数，模型在低温下更容易生成符合Schema的JSON。

这种报错最坑的地方在于：它经常是偶发的。同一个工具定义，今天跑得好好的，明天同一个问题突然失败——因为模型生成带有随机性，某些结构它大多数时候能生成对，偶尔生成错。所以生产环境下，工具调用解析层必须加一层“宽容解析”：先用严格模式解析，失败了再用宽松规则清洗字段，再不行就让模型自己修正一次。

3.3 “Agent execution terminated due to error”到底该不该重试

“agent execution terminated due to error”这条报错，字面意思是“Agent执行因错误终止”，但坑就坑在它过于笼统。真实场景里，它可能是工具超时、网络抖动、模型上下文溢出、工具断言失败中的任何一种。笼统报错不可怕，可怕的是程序把“重试逻辑”无差别地套在了所有错误上。

以我这边实际跑过的任务为例子，重试策略需要按错误类型区分：

• 瞬时错误，比如网络超时、限流、第三方API暂时不可用，建议指数退避重试2到3次，每次间隔至少1到2秒；
• 逻辑错误，比如模型调了一个没有权限的工具、生成了非法参数，重试100次也不会成功，应该直接终止并把错误原因拆解后回传给用户；
• 上下文相关错误，比如模型输出被截断导致后续无法继续，合理的做法不是重试，而是压缩上下文或者换一个入口重新编排。

除了重试策略，更重要的一个治理手段是给Agent执行定义“终止语义”。在我自己的系统里，每个任务会记录“终止原因码”（比如tool_limit_exceeded、user_cancelled、error_no_retry），“Agent execution terminated due to error”只是一个门面文案，真正的排查需要看完整的执行轨迹——每一步模型调用的token消耗、每一条工具调用的请求和响应、每条错误发生的位置。没有轨迹的重试都是瞎试。

所以“到底该不该重试”这个问题，我的答案是：不许裸重试。重试前必须先回答三个问题——错误是可重试类型吗？距离上次重试有没有冷却时间？出现多少次失败后要转入人工？回答不了这三个问题，那就不该自动重试。

4. 工具链上新：从命令行Agent到JVM生态的落地尝试

4.1 Codex CLI：OpenAI把代码Agent放进了终端

今天“welcome to codex, openai's command-line coding agent”的热度不算低，背后是一个明确的信号：产品团队开始把Agent从“网页对话框”搬到“命令行工作流”里。OpenAI把Codex定位成一个基于聊天授权的命令行编码工具，开发者可以在终端里用自然语言描述任务，由Agent直接操作代码库、执行命令、读取错误输出并迭代修复。

从工程角度来看，这类CLI Agent的架构核心都是一个闭环：接收任务 → 扫描工程上下文 → 生成修改计划 → 执行文件读写或命令 → 观察输出 → 决定下一步。它和传统IDE插件的区别在于，CLI Agent默认拥有“执行命令”这个权限。权限意味着风险，所以这类工具在设计上通常会在敏感操作时请求用户确认，并能在授权前展示将要运行的命令。

对团队来说，Codex这类工具带来的管理问题比技术问题更值得提前思考：代码入库前是否要对Agent产生的改动做强制人工review？Agent的API调用如何接入公司的计费审计体系？如果不提前把这些问题定了，团队用上AI写代码之后，代码质量追溯会变得非常困难。

4.2 ADK.dev的Kotlin快速上手：在JVM上跑通一个Agent的路子

今天还有一条值得实操的信息：ADK.dev提供了Kotlin快速上手教程，能在JVM上跑通一个Agent。对Java和Kotlin生态的开发者来说，这算是把Agent开发从Python独占的圈子里往自己熟悉的阵地拉了一大步。

具体路径其实不复杂：先准备好JVM环境和构建工具，然后按官方快速开始文档，通过Gradle引入Agent开发依赖，接着在src/main/kotlin下写一个简单的Agent配置——包括模型端点、系统提示词以及工具注册表，最后启动本地运行入口，在控制台和Agent做一次问答验证。整个过程如果环境顺利，十几分钟就能跑通。

我比较关心的是JVM生态做Agent的优势和短板。优势在于Java/Kotlin的基础设施非常成熟：你在Spring生态里的REST客户端、数据库连接池、缓存组件，几乎可以直接复用到Agent的工具层，企业级链路追踪和监控方案也能无缝接入。短板则在于模型服务的SDK成熟度相对Python差一些，碰到一些比较新的模型特性（比如并行工具调用、结构化输出校验），可能需要先自己封装一层适配逻辑。

4.3 Spring AI的Agent化：Java老兄弟们也能跟上节奏

和ADK.dev同方向的信号是Spring AI这层框架。Spring AI把LLM调用抽象成了类似Spring Data的“模板“风格，让熟悉Spring的人能以极低的学习成本接入对话、结构化输出和向量检索等能力。今天热词里提到“spring ai agent”，更多是它在Agent方向的编排尝试——把工具调用、记忆存储、执行循环都做进Spring的容器模型里，用配置类声明Agent的组件。

这种方案对于存量Java系统很友好。举个例子：公司已经有一个用Spring Boot写的订单系统，希望让用户通过自然语言查询订单状态，就不需要把整个系统用Python重写，只需要在现有工程里引入Spring AI，注册一个订单查询工具，再写一个Agent配置，就能把旧的REST接口变成Agent可调用的能力。

不过Spring AI的Agent编排能力目前相对于Python生态成熟框架还是有差距，尤其在多步骤规划、复杂记忆管理方面偏基础。如果你在做一个严谨的生产级Agent，用Spring AI做接入层可以，编排层建议还是落在自己可控的设计上。

4.4 Hermes Agent与Obsidian：第三方工作台的另一种玩法

“hermes agent obsidian”这个组合词出现得稍微有点突兀。Obsidian是笔记软件，Agent和它放在一起，大致是有人在做“基于个人笔记知识库的Agent工作台”——Agent通过读取Obsidian库里的Markdown文档，帮用户做信息抽取、写作辅助和双链整理。

这类第三方工作台玩法的价值，不在于Agent本身有多聪明，而在于它把“知识库”变成了Agent可以操作的“私有记忆”。对个人用户来说，这意味着Agent不再需要每次从零学习你的背景，它能直接从你的笔记中理解项目上下文、写作风格和知识结构。

但这也正好接回今天AgentPoison那篇的内容：一旦知识库可以被Agent读取，也就意味着知识库可以被投毒。把Obsidian库暴露给Agent时，文件来源的信任边界要想清楚，本地文件可信程度高，但从网页剪藏或同步插件进来的内容就要提高警惕。

5. 学习路线的两种打开方式：从“看懂概念”到“写出框架”

5.1 “Agent是什么”没有统一答案，但可以这么入门

今天至少有三个热词都在问同一个问题：agent是什么。不同背景的人需要的定义是不同的。对业务方来说，Agent是一个能够独立完成多步任务的“数字员工”；对后端工程师来说，Agent是一个带循环的程序结构；对算法工程师来说，Agent是一个把大模型从“对话工具”变成“决策系统”的包装层。

我的建议是，如果你刚开始接触，没必要纠结那个完美的定义，直接记住一个最小结构就行：Agent = 大模型 + 工具集 + 记忆系统 + 控制循环。

• 大模型负责推理和决策；
• 工具集负责“动手”，比如搜索、调API、执行代码；
• 记忆系统负责保存历史信息和长期偏好；
• 控制循环负责决定“下一步做什么”，直到任务完成。

你把这四个组件拆开理解之后，再去看任何Agent框架，都会发现它们只是在用不同的方式实现这四个组件。与其被五花八门的框架绕晕，不如先自己动手写一个十行代码的极简循环：让模型决定调用哪个Python函数、执行结果再喂回模型、直到模型输出结束。跑通一次之后，概念自然就理解了。

5.2 框架与编排：该自己搭还是该用现成的

“agent框架与编排”是今天另一组热词。框架负责给你兜底的套路，编排负责把一个个组件按你需要的方式串起来。这两个词的区分想清楚之后，就能回答“我到底要不要自研”这种问题了。

我的判断标准是看两个维度：业务复杂度和团队熟悉度。如果你的Agent只是调用一两个工具、完成一轮问答，那直接用现成框架就好，省下来的时间拿去打磨提示词；如果Agent需要处理大量分支状态、多个记忆来源、复杂的工具依赖，那框架的抽象反而会阻碍你的控制力，这时候自己写编排逻辑可能更痛快。

编排这件事本身有几个绕不开的关键问题：任务拆分的粒度（多大算一个子任务）、步骤执行失败后是否要回滚、一个步骤的输出如何映射成下一步的输入。这些问题没有标准答案，但都必须在设计编排时显式回答，而不是让模型在每一步临时发挥——临时发挥的方案，线上跑一个月之后你会发现自己根本没有能力排障。

5.3 Harness和Agent的区别：一个容易说混的概念

今天把“harness和agent区别”单独挑出来，是因为我见过太多人在代码评审里把这两个词混用，导致沟通成本剧增。在我理解中，它们的边界是这样：Agent是“做决策的那一层”，它接收任务，选择工具，生成下一步动作；Harness是“承载执行的那一层”，它提供运行环境、负责代码执行、管理沙箱权限、采集日志。

用体育界的类比来说：Agent是运动员，Harness是训练场和裁判系统。运动员决定怎么跑，训练场提供跑道、计时器和规则；没有训练场的运动员跑不起来，没有运动员的训练场没有意义。

放在代码层面，你在LangChain或者自研环境里写的那个AgentExecutor，里面既有Agent的决策逻辑，也有Harness的执行逻辑。真正区分它们，是为了让你在设计时能分开考虑：决策层要关注模型提示词和工具选择策略，执行层要关注权限沙箱、超时控制、异常捕获和数据隔离。这两层如果混在一起写，安全加固时会非常痛苦——因为你不知道要改的权限逻辑到底会影响哪部分决策行为。

6. 日报之外：评估方法、安全边界与几条个人建议

6.1 LLM as Judge能用，但别把它当成唯一裁判

今天“LLM as judge”也是一个稳定热词。用大模型来评判另一个大模型输出的质量，已经成为评估Agent产出的主流手段，尤其在开放式任务里，传统指标根本算不出“好坏”，只能让模型来打分。

但我建议所有评估方案至少要有三层设计：第一层是确定性规则，比如格式合法性、必填字段、数值范围，这些不需要模型判断；第二层是LLM作为裁判，用于评估相关性、逻辑性、语气等主观维度；第三层是小型人工抽检，用来校准第二层裁判的可信度。只靠“LLM as Judge”打分，最大的风险是同源偏差——你用做裁判的模型和回答问题的模型可能是同一家，它们的偏好在评分时会互相强化。

实际操作中，可以让两个不同的模型互评，或者让同一个模型在截然不同的提示词模板下对同一份答案评分两次，再对比结果。如果两次评分差异大，说明当前评估任务本身不适合用LLM直接判，需要拆出更多可量化的子任务。

6.2 Red-teaming该成为Agent上线前的固定步骤

把今天Agent安全相关的热词串起来看，AgentPoison、红队、安全治理，本质都是同一个诉求：Agent不能裸奔上线。和传统后端接口的渗透测试不同，Agent的红队测试更关注“提示词边界”和“工具权限滥用”这两件事。

以我们团队的操作为例，每次Agent版本上线前，会有固定的“攻击清单”跑一轮：让Agent尝试越权访问工具、尝试读取超出权限范围的文件、尝试在被注入隐藏指令的文档下完成正常任务。这些测试不需要复杂工具，一组精心构造的提示词脚本就够用。等到Agent渲染出的行为开始出现“被引导偏离主任务”的情况，就说明边界设计失败，要重新收紧记忆来源和工具权限。

注意：安全测试如果只在开发环境里做一次就完事，效果会大打折扣。Agent的策略文件（包括技能定义、记忆数据）每次更新，都应该触发一次回归测试。

6.3 给今天日报读者的三条手记

最后按惯例放三条短建议，都是今天信息里提炼出来、可以立刻用上的操作：

• 如果你今天刚开始学Agent，不要一上来就选框架，先用一个模型API写一个十行以内的循环，把“模型决定调用哪个工具”这件事跑通，再决定要不要上框架；
• 如果你正在排查“provider rejected the request schema or tool payload”，先把工具定义精简到只有一个必填字符串参数，跑通后再逐步加复杂度，能快不少；
• 如果你打算把Agent放进生产环境，无论规模多小，先给它配上最大步数限制和终止原因码，这两个东西能在系统出问题时帮你省下至少一个通宵。

今天日报的内容就到这里。明天我会继续留意Spatial LLM的落地案例、Agent Skills更新和红队框架的新动态，有新东西再整理出来。