写今天这份日报的时候我盯着热搜词列表看了好一会儿发现一个很明显的信号Agent和LLM这两个词已经彻底分不开了而且大家问的问题越来越“实”——什么harness和agent区别、agent怎么扛并发、llm request failed报错怎么办、安卓能不能本地跑gguf模型。这已经不是“什么是Agent”的科普期了默认大模型能力不是瓶颈真正让人头疼的是怎么把Agent装进自己的工作流、让它稳定地干活还不出幺蛾子。所以这期日报我不打算把热词抄一遍而是把它们按“能解决什么问题”重新分组把背后的原理、坑点、可复现的步骤拆开讲。适合谁看正在做Agent应用开发的人、被各种LLM框架选择困扰的人、以及想从热搜里捞一点真实行业信号的朋友。今天的信息量不小该给命令给命令该讲原理讲原理不废话。1. 从热搜词看风向Agent正在从“能聊天”转向“能干活”这期热搜词里有一批词特别显眼spatial llm、agent anywhere、hermes agent obsidian、agent画图、pi agent。它们放在一起画出来的行业图景很清晰——Agent不再追求“什么都能聊”而是开始往具体场景里扎。1.1 spatial llm大模型开始理解空间位置spatial llm能上热搜说明大家已经不满足于让LLM只处理文字了。机器人导航、AR眼镜、自动驾驶这些场景需要模型回答“这个杯子在我左边多少厘米”“那扇门在我的哪个方向”这类带空间坐标的问题。传统的LLM没有3D感知能力你给它一张图片和一句“帮我找桌上的钥匙”它只能描述画面内容说不出钥匙的三维坐标。2026年这个方向的实际进展核心是把3D位置信息注入token的embedding里配合相机参数和点云数据做预训练让模型从图像输入直接输出物体的3D位置。做具身智能或者室内导航的朋友我建议把spatial VLM这类模型列入观察清单。实测下来这类模型目前的强项是“单张图里的空间关系理解”距离实时视频流里的连续定位还有一段路但趋势已经很明确了空间理解正在成为多模态Agent的标配能力而不是实验室里的新鲜玩意。1.2 agent anywhere与hermes agent obsidian场景才是Agent的归宿agent anywhere这个热词的意思是Agent不应该停留在网页对话框里它应该出现在操作系统、浏览器、笔记软件、IDE这些用户真正工作的地方。hermes agent obsidian能挤进热搜就是因为有人把Agent接到了Obsidian笔记库里让它直接读写本地的Markdown文件做检索、摘要、卡片整理。这个项目最值得学习的地方在于它的轻巧Obsidian的内容是本地Markdown文件Agent相当于通过文件系统直接和你积累了几年的知识库对话。你不用把笔记导入数据库、不用搭复杂的RAG服务一个本地Agent就能实现“问我的历史笔记”这件事。同理agent画图也在热搜里它本质上是多模态Agent调用绘图模型后自己做参数调整——用户说“画一张日落下的城市剪影”Agent自己去调采样步数、提示词权重、画面比例而不是人手动去调。这类工具的共同逻辑是把LLM的能力以最轻的路径接进用户已经在用的工具而不是让用户迁就Agent去新的平台。1.3 pi agent个人智能体的雏形开始出现pi agent——personal intelligence agent这个方向的热度上升很快。它和通用Agent的区别在于长期运行、有记忆、知道用户过去做了什么。pi agent上热搜说明个人助理型Agent开始从演示走向日常使用。一个能记住你上周写的方案、知道你的常用表达习惯、会在你开工前把相关材料准备好的Agent比一个能回答任何问题但没有记忆的Agent有用得多。这也是为什么agent记忆会单独立一个热搜词——没有记忆Agent只能是一台没有历史记录的问答机。2. “harness和agent的区别”能上热搜说明大家开始纠结框架路线了这个月热搜词里harness和agent区别、agent框架与编排、spring ai agent、llm框架这几个词扎堆出现。概念混战的背后其实是框架选型焦虑项目到底该用哪个层级的抽象自己写的代码哪些属于agent哪些属于harness2.1 用“马和缰绳”来理解这两个概念harness英文原意是马具、挽具在这个语境下指的是包含模型调用、工具注册、状态管理、执行循环在内的整套控制框架。agent则指那个“思考—决定—调用工具—观察结果—再思考”的决策循环本身。我常用的类比是agent是马harness是马车和缰绳系统。马负责跑缰绳负责让马按路线拉货。没有harness马跑得再快也没法干活没有agentharness再完整也只是空转。实际开发里这个边界经常被混淆。你写了一个函数让LLM调用天气API这是工具你定义了一个循环让LLM决定要不要查天气、查完怎么回复用户这是agent你把整个循环包装成可配置的流程、加上错误处理和日志这是harness。很多人纠结“我做的到底算不算Agent”其实就是没分清这三层。2.2 Agent框架与编排别一上来就选全家桶agent框架与编排、llm框架这些热搜词背后的真实需求是我想快点把Agent跑起来但不想从零造轮子。我的建议是先别急着上全家桶用几十行代码把核心循环手写跑通再做选型。一个最小的agent循环只需要三件事调用LLM接口传入当前上下文和可用工具的schema描述。解析返回结果判断模型是要直接回答还是要调用工具。如果要调用工具执行工具并把结果追加回上下文继续循环。这个最小实现跑通之后你再去看各类框架就能看懂它们到底帮你封装了什么——状态管理、工具注册机制、回调钩子、可观测性。你在热词里看到的spring ai agent本质就是把这套循环用Java生态的语言和Spring的依赖注入风格重新实现了一遍方便Java团队接入。选框架的时候别只看谁Star多要看它封装的抽象和你团队的技术栈以及你的业务场景是否匹配。2.3 agent记忆与agent安全两个常被低估的工程问题agent记忆上热搜是因为大家发现没有记忆的Agent很难真正成为生产力工具。工程上记忆通常分三层短期上下文、长期向量记忆、结构化记忆。短期上下文就是对话窗口长期向量记忆是把过去的信息做embedding存进向量库需要时检索回来结构化记忆则是把用户偏好、项目状态等信息用格式化的方式保存。三层配合才能让Agent既记得住又不被上下文撑爆。agentpoison这篇红队论文——全名是AgentPoison: Red-Teaming LLM Agents via Poisoning Memory or Knowledge Bases——上热搜说明安全视角也在跟上。它的攻击思路是通过污染Agent的记忆库或外部知识库让Agent在后续决策中被诱导执行攻击者的意图。这对做Agent应用的人来说是个很重要的提醒当你的Agent开始读取外部知识库时输入源不可信就变成了安全边界问题。向量检索出来的内容不能默认可信关键决策要对信息来源做验证和分级。这跟做人一样越是“记住了”的东西越要小心它是被谁塞进来的。3. 把“key-query-value”和“llm as judge”拆开聊透理解LLM的两个关键抓手这期热搜里有一个非常经典的词条“llm的token三个点——key我是谁、query我在找什么、value我能提供什么”。这个概括其实把Transformer的attention机制讲得非常清楚。另一个同样值得展开的是llm as judge天天有人用它做评测但很少有人聊透它的局限。3.1 key-query-value理解token之间如何互相“找关系”attention机制里每一个token都同时扮演三种角色。key是它的“身份标识”相当于每个人胸前挂的工牌query是它的“检索条件”相当于它正在喊“我要找负责数据库的人”value是它实际携带的信息相当于这个人真正能提供的资料。所有token两两之间算attention分数就是拿我的query去匹配你的key匹配度越高我越关注你的value最后把所有人的value按关注度加权汇总得到我这个位置的新表示。这个机制最直接的工程启示是为什么上下文越长大模型推理越慢。因为每个token都要和所有其他token做两两匹配计算量随序列长度呈平方级增长。很多优化方案——稀疏注意力、线性注意力、KV Cache——本质上都在想办法减少这个两两匹配的开销。你手动调prompt时把关键信息放在离问题更近的位置更容易被模型“注意到”也是因为这个机制。3.2 llm as judge用大模型当裁判先知道它的偏见llm as judge火的根本原因是便宜、快。人工评测一份回复要几分钟用GPT级别模型打分只要几秒钟。但实际使用中裁判模型有几类很明显的偏差位置偏差同一个回答放在A位置得分比B位置高。长度偏差写得更长的回答更容易拿高分哪怕内容啰嗦。自我偏爱裁判模型倾向于给自己同系列模型的输出打高分。实操建议是用llm as judge做粗筛没问题批量过滤明显差评的回复但关键指标一定要配合确定性测试比如代码能否通过单元测试、事实性内容是否正确和人工抽查。做对比评测时至少把两个回答的先后顺序交换跑两遍抵消位置偏差评分标准里用具体可观测的维度比如“是否包含明确的数字依据”而不是“质量更好”这种抽象词。3.3 open llm leaderboard等公开榜单怎么用才不被带偏大模型llm、open llm leaderboard等公开榜单这些热搜词说明很多人的模型选型还是看总分。这里我特别想提醒一句榜单总分是“平均分”而你的业务是“某一科”。一个模型可能在代码生成上满分、在中文对话上一塌糊涂平均分依然能排在前面。正确用法是先明确自己的任务类型再去榜单里看对应细项分数。更靠谱的做法是准备20到50条你业务里的真实数据两个模型各跑一遍自己看输出质量实测永远比榜单更接近真相。llm wiki这类热词也是在解决同样的问题——把模型信息结构化整理让人不用靠标题党来了解模型。4. 今天最值得背下来的三类Agent事故现场与处理思路这期热搜里的报错类词条特别有参考价值codex无法发送消息显示更新agent沙盒、llm request failed: provider rejected the request schema or tool payload、agent execution terminated due to error。这三个都是Agent开发里出现频率最高的真实事故我把排查思路完整捋一遍。4.1 codex无法发送消息显示更新agent沙盒用Codex这类Agent编码工具的朋友看到这个提示大概率一脸懵。它说的是Codex的agent沙盒和环境状态出了问题。沙盒是Codex用来隔离运行环境的机制但它和IDE之间的联动经常掉链子。实测下来按这个顺序排查成功率最高先确认是不是会话过期退出当前会话重新创建一个很多情况下是会话状态和沙盒不同步。检查工作目录确认当前IDE打开的项目路径和Codex沙盒挂载的路径一致路径错位会导致Agent以为环境不存在。如果提示“更新agent沙盒”是反复出现的大概率是本地Codex版本和服务端版本不一致升级CLI到最新版删掉旧的会话缓存文件再重试。这个问题的本质是“本地环境状态”和“Agent运行环境状态”没对齐跟业务代码没关系所以别慌按步骤清理就好。4.2 llm request failed: provider rejected the request schema or tool payload这个报错的关键词是provider rejected说明请求已经发到了服务商那边是服务商拒绝了你请求里的结构。结构性和网络错误是完全不同的两类问题网络错误是链路不通这个报错是你的请求格式不符合API规格。最常见的两个坑工具函数的JSON Schema不合法给工具参数定义了复杂的嵌套对象但没写required字段或者type和实际传入的内容对不上。请求payload里混进了不该出现的东西比如把内部密钥、自定义字段塞进了发给服务商的请求体服务商校验失败直接拒掉。排查思路是先单独构造一个最小请求用官方API文档里的例子跑通再逐步加工具定义定位到具体是哪个工具的schema出了问题。一个最小工具定义长这样{ name: get_weather, description: 根据城市名查询天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } }注意parameters里必须显式声明required描述字段也要写清楚。缺了required模型可能生成空参数服务商那边校验直接拒。提示设计工具函数时把payload当成对外接口契约来管新增字段先校验再上线能避开一大半这类报错。4.3 agent execution terminated due to error与ai agent怎么扛并发agent execution terminated due to error是Agent运行循环里最笼统的报错Agent在某个环节出了问题被终止。可能的原因包括工具调用抛异常、LLM调用超时、上下文超出窗口长度。处理这类问题不能只看最后的错误提示要给Agent运行时加日志埋点把每一步的输入输出都记录下来。我的经验是Agent执行必须设计成可重试的异步任务不能一条道走到黑。重试用指数退避策略第一次失败等1秒第二次等2秒第三次等4秒避免雪崩式重试把API打爆。ai agent怎么扛并发这个问题单独上热搜说明有人开始把Agent当正经服务来做了。Agent的并发设计和普通API服务不一样单个Agent任务可能耗时几十秒甚至几分钟中间还可能穿插多次LLM调用而LLM API又有速率限制。核心架构是队列加Worker池而不是直接同步调用请求进来先入队立刻返回任务ID给调用方。Worker从队列取任务每个Worker串行执行完一个Agent任务再取下一个。Worker数量按LLM provider的速率限制和你自己的延迟要求来调比如每分钟允许600次请求单个任务平均要调5次LLM那最大并发大概可以冲到100个Worker附近。关键路径上的单次LLM调用要设超时超时就重试或者降级不能让一个任务把整个Worker占死。这个架构跑起来之后你还要盯两个指标队列积压时长和任务失败率。队列积压说明Worker不够失败率高说明工具调用或者提示词有问题先把这两个指标稳定下来再谈优化。5. 学习路线与工具链盘点今天可以动手复现的几件事热搜里有一大批学习路线类和工具安装类的词条agent开发学习路线、agent开发教程、claude agent skills: a first principles deep dive、hermes agent安装、adk.dev的kotlin快速上手在jvm上跑通一个agent、基于rust语言ai agent、基于llm的单元测试、安卓本地运行gguf格式llm软件。我把它们按“从学到做”的顺序理一遍。5.1 agent开发学习路线从最小循环到工程化我看到的agent开发学习路线热词折射出的问题是大家不知道先学什么后学什么。我的建议分四步走先把大模型API调明白熟悉token是怎么计费的、temperature和top_p分别影响什么、上下文窗口满之前有什么表现。这对应llm是什么、llm的token这些热搜词。手写一个最小Agent循环给Agent配一个工具让它自己决定要不要调用、怎么解读工具返回值。这对应agent是什么、agent架构。找一个轻量框架做实际任务比如让Agent每周自动整理你关注的几个网站的热门文章。在这个阶段你自然会接触到agent框架与编排、agent框架这些词。往上走就是agent记忆、agent安全、llm as judge、并发生产部署。每一步都用一个小项目练手比盲目刷概念强很多。5.2 claude agent skills: a first principles deep dive值得精读的一篇这篇文章标题本身出现在热词里说明很多人把它收藏了但还没读。先说结论Agent Skills的核心是把工具从“单个API函数”升级成“可组合的能力包”。一个skill就是一个包含prompt、工具定义和资源文件的目录Agent可以在运行时发现、加载并调用。这样做的好处是复杂能力可以被封装成标准化的单元换模型、换框架时skill可以复用。想动手体验的话在Claude Code项目里建一个.skills目录把一组相关工具和说明文档放进去Agent就能自动识别并调用。这比把十几个工具函数堆在一个文件里清晰得多也让Agent面对新任务时更容易发现“我有什么可用”。5.3 hermes agent安装、adk.dev kotlin与rust agent三条工具链各自的位置hermes agent安装和hermes agent第三方工作台这两个词条挨在一起说明大家在安装时容易被生态里的第三方GUI搞晕。重点说一句看官方仓库看release版本先跑起来官方CLI再考虑第三方工作台。很多所谓安装失败是因为装了第三方封装版却用官方文档的配置方式去启动。adk.dev的kotlin快速上手在jvm上跑通一个agent这个热搜很有意思说明有人在尝试在安卓或者JVM后端里直接跑Agent。思路是用Google的Agent开发套件ADK的Kotlin DSL定义Agent通过Gradle引入依赖在本地JVM里跑通最小示例。而基于rust语言ai agent的词条则是另一条路线Rust的运行时性能好、内存可控适合做嵌入式的Agent执行引擎。工具链没有绝对的优劣看你运行的平台和团队的语言栈。5.4 基于LLM的单元测试与本地部署两个落地场景基于llm的单元测试是很多团队正在探索的方向用LLM生成测试用例、验证自然语言描述的行为。我的实际体会是LLM生成测试用例确实能覆盖很多开发者懒得写的边界场景但断言一定要落到确定性检查上。LLM写出来的判断结果不能被直接当成测试结论最终还是要比对实际返回值、文件内容、数据库状态这类可验证的东西。不然测试结果本身都不可信那测试就失去了意义。安卓本地运行gguf格式llm软件、支持安卓8这两个词条放在一起说明大家的诉求是在旧安卓设备上跑本地模型图的是隐私和离线可用。gguf是llama.cpp系列的量化模型格式安卓上可以选用支持该格式的本地推理应用。要点是选对量化和模型大小安卓8设备的性能有限推荐用Q4_K_M这种平衡型量化等级模型参数控制在7B以内并且留意应用是否声明支持你的安卓版本。实测下来老设备跑7B模型推理速度会比较慢适合异步处理任务不适合做实时交互。最后说一点我自己写日报时的实际感受。热搜词里出现大量报错类问题和“怎么扛并发”这类工程问题在我看是好事——说明Agent/LLM正在从“演示赛”进入“正赛”阶段。我处理llm request failed这类问题时的体会报错信息里provider rejected其实比network error好处理得多前者说明你的schema有问题后者说明整个链路都不可控。所以建议大家在设计阶段就把工具调用schema当成接口契约来管严格校验能省掉后面一大半的排查时间。这个领域每天都有新框架、新概念冒出来但底层的东西——token机制、attention、工具调用、记忆、评测——一直是那些。把这个打扎实换什么框架都不慌。