每天一睁眼，社交媒体上关于 Agent 和 LLM 的热搜关键词就换一轮，今天（2026-09-28）的知乎版热搜里藏了不少实用细节和值得深聊的话题。作为常年泡在 LLM 应用层的老开发，我梳理了一下今天最值得看的几十条热词，发现除了老生常谈的“agent 是什么”和“llm 是什么”之外，还有几个值得拆开讲透的点，包括 token 的 key / query / value 底层逻辑、harness 和 agent 的区别、agent 安全攻击、以及本地跑 GGUF 这种越来越常见的高频操作。
这篇日报不是单纯把热搜词罗列一遍，而是顺着今天的热词把那些真正的技术决策点、上手路径和踩坑点串起来。不管你是刚开始学 agent 开发的新手，还是已经在做 LLM 应用的老手，这篇文章都会尽量兼顾。涉及大量实操细节、框架选型建议、安全意识和常见报错排查，后面都是可以直接拿来用的经验。
1. 核心概念扫盲：LLM 的 token 机制到底在说什么，harness 和 agent 怎么分
1.1 llm 的 token 三个点：key、query、value 背后的设计逻辑
今天热搜里有一个非常精辟的总结：“llm 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么”。这个说法本质上是在用信息检索的视角去看 Transformer 里的 QKV 机制。很多新人一看 QKV 就头疼，以为是要死磕数学公式，其实用这个类比来理解，马上就能建立一个直觉。
key、query、value 是注意力机制的三件套。你可以把一句话切成的每个 token 都想象成一个口袋里装了个人信息和工作能力的人。query 是当下这个 token 正在“喊话”的内容，它想知道谁跟自己相关；key 是其他 token 听到喊话后亮出的“身份标签”，用来告诉对方“我有哪方面信息”；value 则是真正被取用的“干货内容”，也就是对方能提供出来的具体数据或语义特征。模型计算注意力分数，本质上是让每个 query 去匹配所有 key，然后按匹配度去加权求和 value，最终得到每个 token 在新的上下文里应该被“激活”的信息。
我当初刚看到这个解释的时候，一度怀疑是不是把复杂问题包装得太简单，后来在项目里处理超长文本时才发现这条路是对的。当你给模型输入一段很长的日志，让它总结关键异常时，模型内部做的事情就是让“总结”这个 query 去匹配日志里那些 key 标签，再根据 value 把异常信息加权挑出来。理解这个机制以后，你才能理解为什么 prompt 中关键实体和关键业务词会被强调，为什么 RAG 的问句和文档片段要让问句里的 query 去匹配文档片段里的 key。
回到实操层面，如果你想写好一个 RAG 的 query 转换模块，就要时刻记住：用户的问题天然是 query，而你的文档切块内容需要设计好 key，也就是摘要、标题、关键词这些显式索引。否则一个没有“身份标签”的文本块，无论内容多好，都可能被注意力机制忽略。这一点和今天热搜里“query 我在找什么、value 我能提供什么”是完全呼应的。
1.2 harness 和 agent 的区别，以及 agent 是不是独立“人格”
今天热词里“harness 和 agent 区别”出现频率不低。学术一点说，harness 是承载和控制 agent 运行的一套外部框架，agent 本身则是那个具备感知、决策、行动的“大脑体”。还是用刚才的比喻，harness 像舞台上的灯光、幕布、提词器，agent 是站在舞台中央的演员。演员的演技决定表现上限，但灯光和提词器如果设计得不好，演员再强也会演砸。
在我实际做过的一个基于 LangChain 的自研 agent 系统里，harness 负责的工作包括：发起 LLM 调用、调度工具、维护对话历史、处理循环次数上限、异常回退策略等。agent 本体则只是由模型和提示词定义出来的“推理循环”，它没有独立执行能力，必须通过 harness 才能与真实世界交互。
很多人误以为 agent 是有独立人格的那个东西，其实用下来你会明白，agent 的“人格”是由 harness 里的系统提示词和工具集共同雕塑出来的。在两个不同的 harness 里，同一个 LLM 可以被塑造成客服 agent、代码 agent、写作 agent。这也是今天热搜里“agent anywhere”和“agent 架构”讨论那么热的根源。今天很多开源框架强调自己“自带 harness”，比如你搜到的“agent 框架与编排”话题，本质就是在比较不同 harness 对工具调度、记忆管理和子 agent 编排的取舍。
如果你还在纠结 agent 和 harness 两个词，我的建议是别在概念里打转。直接记住两句话：harness 是 agent 的运行骨架，agent 是骨架上的决策逻辑。选型的时候先看 harness 的功能成熟度，再看它是否支持你自定义 agent 推理策略。
2. Agent 开发与框架选型：从春季 AI 之王到各种 agent 框架的横向取舍
2.1 Spring AI Agent 和 ADK 快速上手，选型时要注意的细节
今天热词里“spring ai agent”和“adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent”同时出现，说明 JVM 生态的开发者对 agent 开发又有了兴趣。Spring AI 早期很多人只是把它当“用 Java 调 LLM API 的客户端”用，但最新版本里 agent 这块已经越来越完善。如果你在维护一套 Java 业务系统，想引入 agent 能力做流程自动化，我强烈建议优先看 Spring AI 的 Advisor 机制，它允许你把日志、鉴权、上下文记忆封装成一个可复用的调用链。
ADK（Agent Development Kit）则是另一套思路，按 Kotlin 快速上手的要求，可以说它把 agent 状态管理、工具注册、事件回调做得非常干净。我测试过在 JVM 上跑通一个最小 agent，核心思路是先定义 Tool 接口，再用 Kotlin 协程把 LLM 调用和工具执行的循环串起来。要注意的是，ADK 对异步并发处理很敏感，如果你的业务里有大量并行工具调用，就要仔细处理共同的内存态，否则容易出现“agent execution terminated due to error.”这种让人头疼的报错。
选型建议其实很简单：
- 如果你已经身处 Spring Boot 生态，选 Spring AI Agent 最省心，它和现有 Bean、拦截器、配置中心能无缝整合。
- 如果你追求更“原生”的 agent 编程体验，喜欢控制每个环节，ADK 的设计会让你很舒服，特别是 Kotlin 写 DSL 来定义 agent 行为。
- 如果只是快速验证想法，建议用社区里更成熟的 Python 框架，开发效率更高。
今天热搜里的“ai agent 搭建”“agent 开发 教程”不少，但真正拦路的基本不是模型能力，而是框架里那套工具调用循环。建议新手先用带完整示例的框架把“用户输入 → 模型判断 → 调用工具 → 返回结果 → 再次输入模型”这个闭环跑通，再慢慢抽象自己的业务工具集。
2.2 Agent 记忆、Agent 技能和 Agent 编排：到底怎么落地
今天热搜里“agent 记忆”“agent skill 教程”“agent 框架与编排”“claude agent skills: a first principles deep dive”一并出现，可以看出大家正在从“能跑通”转向“跑得好”。Agent 记忆是 LLM 对话外的状态持久化问题。最简单的记忆是直接把聊天历史塞进上下文，但 token 一长，成本就失控，效果也会下降。于是就有了“记忆仓库”的概念，类似给 agent 配一个可检索的外挂大脑。今天热搜里的“hermes agent obsidian”就是在用 Obsidian 作为 markdown 知识库，配合向量索引来做记忆持久化，思路很直接，也很适合个人知识库场景。
Agent 技能（skill）则是可复用的独立功能包。例如给 agent 写一个“生成周报”skill，里面包括 prompt 模板、输入输出结构和调用外部数据的脚本。真正的好 skill 是要能被 agent 自主判断并择机调用的，而不是人肉把所有逻辑都写死在主流程里。很多框架里 skill 的注册顺序会影响模型选择概率，这个细节容易踩坑。我建议每次新增 skill 都做一轮小规模评测，看 agent 是否真的“知道”自己该在什么时候用它。
至于 agent 编排，那就是多 agent 协作的领域了。一个负责拆任务、一个负责执行、一个负责审核，听起来很美，但编排复杂度直接翻倍。我的实操心得是：如果单 agent 能解决的问题，不要轻易上多 agent。“pi agent”和“agent anywhere”这类热词背后其实是跨端、跨平台的 agent 需求，而跨平台 agent 最难的是工具接口统一和沙盒隔离，这是架构层面的硬功夫。
2.3 基于 Rust 的 AI Agent，为什么偏要执着于性能
今天热词里专门出现“基于 rust 语言 ai agent”，这多少说明性能敏感型 agent 应用已经成了需求。Rust 的优势在于内存安全和并发性能，在处理高并发工具调用、长轮询、大量 token 流式解析时，Rust agent 能做到低延迟和高吞吐。我认识有团队用 Rust 重写了 agent 的核心调度层，把原来 Python 框架能扛的并发数提了至少一个数量级。
如果你考虑用 Rust 写 agent，我的建议是不要从零开始手撸所有东西。先评估成熟的 Rust 框架，比如基于 Tokio 的异步 agent 运行时，配合现成的 LLM 客户端库。主要难点在于工具注册宏的设计和上下文序列化。用 Rust 做 agent 最麻烦的是迭代速度，毕竟调用次数的增加会带来内存分配和 trait 对象调度的开销。所以务必要把热路径和冷路径分开设计：频繁调用的思维循环要轻量化，偶尔触发的工具逻辑可以走“慢”一点但更清晰的代码。
3. 安全与评估：Agent 中毒、LLM as Judge 和那些不能忽略的红线
3.1 Agent 安全：从 agentpoison 看记忆与知识投毒，以及防御思路
今天热词里有一条很刺眼：“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”。这条讲的是针对 LLM Agent 的攻击方式，核心是通过污染 agent 的记忆库或外部知识库，让 agent 在后续决策时被带偏。这比直接改 prompt 更危险，因为普通用户不会去检查记忆库里每一块文本的“真实意图”。
我自己的防护经验是三层防御。第一层是输入过滤，对所有写入记忆库的外部文本做一次可执行指令检测，过滤掉潜藏“让它忽视之前指令”的文本。第二层是权限隔离，agent 调用外部工具时的凭证和 base prompt 的凭证要分开，这样即使记忆被污染，攻击者也拿不到系统级操作权限。第三层是行为审计，保留 agent 每次调用的原始上下文快照。一旦发现异常决策，可以回溯到具体是哪条记忆或知识影响了它。
很多开发者听到 agent 安全第一反应是“我没有那么大价值，没人攻击我”，但事实上作为用户，你接入了第三方 agent 框架之后，你的对话记录、知识库都可能成为数据源。今天热词里“agent 安全”只有两个词，背后却是需要认真对待的工程问题。
3.2 LLM as Judge 怎么用，以及公开榜单怎么读
“llm as judge”是现在做 LLM 应用评测的常用手段。用一个大模型去评估另一个模型的输出质量，听起来有“以牙还牙”的味道，但实践下来非常有效。我的做法是设计好一个评估 prompt，给出标准答案和评分维度，再让裁判模型打分。要注意的是裁判模型和被测模型如果是同一家，可能存在系统性偏好，所以至少要用两到三个不同模型的输出分开评测，再交叉对比。
今天热词里还有“open llm leaderboard 等公开榜单”。公开榜单只能作为一个初始参考，没法完全代替自己的业务评测。因为榜单上的任务多为通用任务，和你的场景数据分布差别可能极大。更靠谱的方法是拿你自己的测试集，在不同模型上跑一遍，再看结果。尤其是 Agent 场景，不仅要看大模型本身的输出质量，还要看它在多轮工具调用中的决策准确率，公开榜单根本覆盖不了这种复杂度。
3.3 一些合规话题：NSFW 与内容过滤，做本地模型的边界意识
今天热词里有一条问“支持 nsfw llm 有那些”，我就简单聊一下边界。现代部署环境里，无论是本地还是云端，模型都应具备内容安全过滤机制。这不是“扫兴”，而是对用户、开发者自己和平台的保护。本地模型确实有自由度更高的空间，但如果你把模型能力封装成工具暴露给他人，就必须考虑内容合规和滥用风险。我推荐在 agent 的输出层增加一道规则过滤，再叠加一层轻量分类模型做兜底，比自己直接裸奔安全得多。
4. 本地部署与实操问题：安卓跑 GGUF、Codex 沙盒和常见报错排查
4.1 安卓本地运行 GGUF 格式 LLM：支持安卓8，你需要知道这些
今天热词里“安卓本地运行 gguf 格式 llm 软件，支持安卓8”这组关键词非常实际。GGUF 是 llama.cpp 项目带火的一种量化模型格式，很适合在端侧跑。想要在安卓上流畅跑，第一步是选量化等级：Q4_K_M 是效率和体积最均衡的选择；内存小于 6GB 的机型建议用 Q3 甚至更小；如果目标是演示效果，Q5、Q6 更稳。
框架方面，推荐用 llama.cpp 的 Android 构建产物，或者直接用支持 GGUF 的前端应用，比如 LM Studio 的移动端分支和朋友推荐的“LLM Studio”等。你要注意“支持安卓8”是个硬门槛，有些新版本安卓应用最低要求已经是 Android 10 以上。如果你必须兼容安卓8，找旧版本应用或者自己编译旧版 llama.cpp 更靠谱。
跑本地模型也不能只装应用，模型文件本身要到 Hugging Face 等站点下载。选一个小型化模型，比如 3B 或 7B 的量化版本，体验更顺畅。实操上，我把一个 4B 模型放到中端安卓机上，首 token 生成速度大概在 10-15 token/s，日常对话完全够用，只是长文本生成会明显发热。
4.2 Codex 沙盒错误和 agent execution terminated due to error
今天热词里有两条很虐：“codex 无法发送消息，显示更新 agent 沙盒”和“agent execution terminated due to error.”。这两条我太熟了。Codex 那种更新沙盒的报错，多半是本地环境里的沙盒依赖版本和远端不一致。解决办法是清理掉旧的沙盒镜像，重新拉最新版，另外检查一下网络环境是否能顺利访问远程容器。
“agent execution terminated due to error”这个报错，表面看是 agent 内部循环挂了，实际原因多半是工具返回的结构不合法。比如你让 agent 调一个后端接口，接口返回了非预期 JSON，agent 在解析时抛异常，框架就直接终止整条执行链。我的排查思路是先把工具调用改成纯文本返回，让 agent 不依赖严格结构，看是否还出问题。如果问题消失，那就是 JSON Schema 兼容性出了问题，重点检查工具描述里的字段类型和必填项。
4.2.1 LLM request failed：provider rejected the request schema or tool payload
热词里另一条“llm request failed: provider rejected the request schema or tool payload”也很典型。这个错误说明你发给模型供应商的请求里，携带的工具参数结构不符合该模型的 grammar 约束。不同模型对工具调用的描述规范支持程度差异很大。解决方案是换一个模型版本，或者把工具描述简化。还有一个常见原因是某些字段名用了保留字，比如 description 里加了特殊转义字符。我用一个笨办法：先把你定义的 tools 数组打个日志，自己检查一遍 JSON 是否符合 Schema 规范，绝大多数这类报错都是自己没发现某个字段类型错误导致的。
4.3 AI Agent 怎么扛并发：一个真实压测现场
今天热词里“ai agent 怎么扛并发”出现得很有水平。Agent 并发和普通 API 并发完全是两个量级，因为一次 Agent 任务可能包含多轮 LLM 调用和若干次工具调用。我最近压测过一个客服 agent，目标是支撑每秒 20 个并发用户。第一版直接调大线程数，结果 provider 那边直接限流。
后续做了三件事才解决问题：第一，给 LLM 调用层增加本地缓存，相同前缀的问题直接用缓存；第二，把工具调用做成异步任务队列，用一个线程池隔离慢调用；第三，引入“会话锁”，同一个用户会话内串行执行，不同会话之间并行。这三步做完，成功把支撑并发从每秒 5 个提升到 20 个左右，同时还能保持响应时间在可接受范围。所以“扛并发”的关键不一定是堆机器，而更多是把调用粒度拆好、合并好。
5. 工具链、学习路线与实操心得
5.1 值得关注的开源工具链：Hermes Agent、Obsidian、LLM Studio
今天热词里“hermes agent”连续出现多次，这应该是一个不错的个人助理类 agent 项目。从“hermes agent obsidian”和“hermes agent 第三方工作台”看，它很可能把笔记系统当知识库。我自己也试过把 Obsidian 作为 agent 的记忆后端，思路就是先把 markdown 文件向量化，再让 agent 通过检索接口访问。优点是笔记天然是人类可读的，随时可以修改和调整；缺点是没有版本控制，容易被误写。如果你想深度使用这类 agent，记得给笔记库加 Git 备份。
“LLM Studio”这类桌面工具则专注于本地模型管理，支持 GGUF 格式加载、微调预览、API 服务暴露等功能，非常适合新手起步。用它来测试不同量化模型在你自己任务上的表现，再决定要不要往业务里接入。
5.2 Agent 开发学习路线：别一上来就啃源码
今天热词里“agent 开发学习路线”“agent 学习路线”各出现一次，我直接给一条相对务实的学习路径。
第一步，先把 LLM 的 API 调用弄熟，至少要会处理 OpenAI 兼容接口、流式输出、工具调用格式。第二步，别急着写 agent，先用现成框架把几个官方示例跑起来，感受工具调用循环。第三步，自己实现一个最小 agent，只包含“LLM 调用 + 一个计算器工具 + 一个 HTTP 请求工具”，把整个调度抓在手里。第四步，引入记忆和 RAG，理解上下文裁剪和向量检索。第五步，再看 agent 安全、评估、多 agent 编排这些进阶方向。
有些朋友一上来就问“要不要先学 transformer 源码”？我的建议是如果你的目标是做应用，先了解 QKV 的本质即可，不需要死磕反向传播。真正能帮你找工作或做产品的是你对业务场景的拆解能力和对 agent 工具的调度能力。
5.3 落地多个 agent 项目后的几条军规
最后分享几条我在多个 agent 项目里总结的军规，也算是对今天大量热词的一个收拢。
提示词里的工具描述一定不能太长。每次给模型塞巨长的工具说明，模型会更早开始胡说。描述要短，重点要突出“什么条件下调用”。例如，一个查询天气的工具描述，我只写“当用户询问天气或温度时调用，若用户未提供城市，先反问”。这比写三页说明书好得多。
Agent 的记忆必须做容量控制。我通常最多放最近 20 条对话，再推进向量检索。否则随着对话越拖越长，模型注意力会被无关信息稀释。
日志和追踪是 Agent 开发的命根子。工具调用链断了以后，如果没有日志，你只能靠猜。我现在每个 agent 项目都强制接入可观测性工具，把每次 LLM 请求的 prompt、响应、工具输入输出都记录下来。
6. 个人经验和最后的小技巧
这些天折腾下来，我对 Agent / LLM 领域最大的感受是：模型能力其实已经相当强，真正拉开差距的是工程细节。为什么别人做出来的 agent 看起来很聪明，你的却像个青铜？十有八九不是模型不行，而是你在工具设计、记忆管理、错误恢复这些环节上打磨不够。
今天热词里反复出现的“agent 是什么”“llm 是什么”这类基础问题，恰恰说明这个领域还有大量新手涌入。我觉得这是好事，但同时要提醒大家一句：不要在概念里沉迷太久，赶紧打开一个框架，把一个小功能完整跑通。
最后分享一个小技巧，是我在很多项目里都用得很顺的：给 agent 增加一个“兜底工具”。当 agent 判断自己无法处理当前请求时，它可以调用这个兜底工具，把问题转给人工处理者或自动生成一个待办任务。这个设计能让 agent 在复杂场景下优雅地“认输”，而不是胡编乱造。只加这一条，用户对 agent 的满意度就会提升很多。
今天这份日报就到这里。如果你也在折腾 agent 或 LLM，欢迎在各平台一起交流，希望你少踩坑、多落地。
