今天是2026年9月28日刷了一圈 Agent / LLM 相关的热门讨论我的整体感受是这个圈子终于从“Agent 是什么、能干什么”的科普期进入到了“怎么把 Agent 做成一个可靠系统”的工程期。今天的高频热词已经不是 llm 模型、agent 是什么这种入门级问题而是转向了 agent 框架、agent 架构、agent 记忆、agent 安全、ai agent 怎么扛并发、llm request failed 这类非常具体、非常落地的话题。这期日报我把这些热词按主题做了归类结合我自己的实操经验做深度扩展重点放在框架选型、模型思维、记忆与安全、生产环境实战四个方向。无论你是刚准备入局 Agent 开发还是已经被项目里的疑难杂症折磨了好几天这篇内容应该都能给你提供一些参考。1. 今日热词速览从问题分布看行业风向我先把今天的热词大致分成六组这样后面展开的时候思路会清楚很多。这不是随便分的类每一组都对应 Agent / LLM 开发周期里的一个阶段也对应着不同基础的人最关心的事。框架与架构类agent框架、agent架构、agent框架与编排、harness和agent区别、spring ai agent、adk.dev、agent anywhere、llm框架、agent项目、agent ransack。模型与理论类llm模型、spatial llm、大模型llm、llm的token三个点、llm as judge、open llm leaderboard、基于llm的单元测试、使用聊天记录模型精调llm、llm wiki。记忆与技能类agent记忆、agent skill教程、claude agent skills、agent画图、hermes agent、pi agent、hermes agent obsidian、presonl agent。安全与风险类agent安全、agentpoison: red-teaming llm agents via poisoning memory or knowledge。生产与部署类ai agent怎么扛并发、llm request failed、codex无法发送消息显示更新agent沙盒、agent execution terminated due to error、基于rust语言ai agent、安卓本地运行gguf格式llm软件支持安卓8、llm studio、llm request failed: provider rejected the request schema or tool payload。学习路径类agent开发学习路线、agent学习路线、agent skill教程、ai agent搭建。这个分布其实很能说明问题。框架、编排、记忆、安全、并发这些词全部指向一个事实Agent 正在从个人玩具走向真实业务系统。早几年大家讨论 Agent场景多半是“让 AI 帮我写个邮件”“让它帮我查个资料”关注点全在模型本身的对话能力上。现在不少人手上的 Agent 已经要承担业务流程中的具体角色比如自动处理工单、操作内部系统、生成测试用例那么“能不能稳定跑”“会不会泄露信息”“并发上来会不会挂”就变成了回避不了的问题。我个人判断接下来半年 Agent 领域的竞争重点会从“谁的 demo 更惊艳”转向“谁的系统更能扛事”。今天的日报其实就是这个转向的一个缩影。2. 框架与架构从 Agent 概念到可运行系统的第一道坎2.1 框架选型主流方案到底怎么选今天热词里的 agent框架、llm框架、spring ai agent、adk.dev 都指向同一个问题我该用哪个框架来写 Agent先明确一个前提Agent 框架解决的核心问题有两个一是“怎么让 LLM 调用工具”二是“怎么编排多步任务”。至于什么多智能体通信、复杂记忆管理那是进阶功能不是框架的基础职责。理解了这一点你就不太会被五花八门的框架搞晕。我接触过的方案大致分三类。第一类是通用型 Agent 框架比如 LangChain 系的 LangGraph、微软的 AutoGen、CrewAI它们把工具调用、多智能体协作、状态管理封装成了现成组件上手快但抽象层级高出了问题不太容易定位。第二类是聚焦单 Agent 工作流的框架比如 OpenAI 的 Agents SDK、一些主打轻量的自研方案它们更强调最简路径适合业务逻辑清晰、不需要复杂协作的场景。第三类是深度绑定某一生态的框架比如 Spring AI它把 Agent 能力嵌入 Java 生态适合企业内部已有大量 Spring 服务的团队。今天热词里的 ADKAgent Development Kit是 Google 的框架最近也有人用它跑通了 Kotlin 在 JVM 上的 Agent 快速上手这类框架的好处是跨语言、可嵌入性强适合有特殊语言栈的团队。如果你问我的建议我会说不要为了用框架而用框架。先用伪代码把你要编排的流程画出来如果流程不超过三步工具调用直接裸写 HTTP 调用都没问题只有当你需要状态管理、多分支决策、错误重试这些能力时才值得引入框架。框架给你的是效率同时也给你带来一层学习成本和排查成本选型本质上是权衡这三者。2.2 Harness 与 Agent这两个词别再搞混了今天有个热词很有意思叫 harness和agent区别。我猜提问者大概率是在读某个开源项目文档时发现一会儿出现 agent 一会儿出现 harness搞不清两者什么关系。其实结论很简单harness 是负责执行 Agent 循环的运行时外壳Agent 是决策核心。Harness 里塞的是循环调度、工具注册、上下文组装、错误兜底这些“基础设施”而 Agent 本身只负责“思考下一步该做什么”。用一个生活类比Agent 是司机harness 是那辆车的动力系统和方向盘司机决定去哪、怎么走但踩油门、刹车、打灯这些动作全都靠车辆的机械结构完成。为什么这个区别这么重要因为它直接影响排查问题的层级。很多新手遇到 Agent 跑出来的结果不对第一反应是去调模型的 prompt但实际上问题可能出在 harness 的上下文截断策略上或者工具返回内容被错误封装了。明白了 harness 和 agent 的边界你的问题定位速度会快非常多。我见过不少团队因为在 harness 层没做好超时控制导致某个工具调用挂起之后整个 Agent 流程卡死这种问题你改十版 prompt 都没用得回 harness 层做兜底。2.3 架构与编排真正决定 Agent 上限的部分框架热词背后更值得聊的是 agent 架构和 agent框架与编排。这两词看着高大上其实就是两个问题我的 Agent 系统分几层各层之间怎么配合常见的 Agent 架构有三种我分别说下适用场景。第一种是单 Agent 自主循环所有工具调用都交给同一个 Agent 循环处理优点是简单直接缺点是上下文容易越积越长思维容易发散适合任务边界清晰的场景。第二种是 Supervisor / Worker 模式一个主 Agent 负责任务拆分把子任务派发给孩子 Agent 执行并汇总结果这种架构适合任务复杂但可拆分的场景代价是要额外处理子任务的中间状态和结果汇总通信损耗不可忽视。第三种是 Pipeline 流水线模式多个 Agent 按固定顺序处理数据每步只做一件事适合流程固定的业务比如“先抽取信息再调用 API最后生成报表”。今天热词里的 agent anywhere 讲的其实是同一件事把 Agent 能力嵌入到不同业务端点。比如在 Slack 机器人里嵌入一个提效 Agent在 CRM 系统里嵌入一个销售分析 Agent这种架构本质上是把 Agent 编排能力通过 API 暴露给各个业务入口。设计时我会建议把“编排核心”和“业务入口”拆开编排核心只负责 Agent 逻辑业务入口只负责接收消息和返回结果这样你接十个入口也不用重写 Agent 逻辑。顺带说一句今天有人问到 agent ransack那其实是一个用来扫描和提取 Agent 行为痕迹的开源工具。想深挖 Agent 编排内部发生什么的人可以把它当作辅助排查工具来用原理上它就是在 harness 层挂钩子把每次循环的关键决策记录导出帮助我们还原 Agent 的“思考轨迹”。对排查复杂问题非常有价值。3. Token、模型与榜单理解 LLM 的底层思维3.1 关于 token 的三个点Key / Query / Value今天关于 llm 的 token 三个点讨论挺有意思有人把它总结成“key 我是谁、query 我在找什么、value 我能提供什么”。这个框架虽然是从检索场景来的但我认为它几乎是所有 LLM 应用设计的通用思维工具。拆开看Key 代表用户身份与背景决定对话的基调和约束条件。Query 代表用户当前的意图决定模型要解决的具体问题。Value 代表系统里能提供的工具、知识、数据决定模型拿什么来解决问题。你可以用它来检查自己设计的 Agent 系统是否有缺口如果系统跑起来效果不好先问一句模型知道“我是谁”吗如果 prompt 里没有明确角色约束和业务背景模型就是在瞎猜语境。再问模型清楚用户“在找什么”吗如果 input format 不够明确模型自然会产出含糊的结果。最后模型真的“能提供什么”吗如果知识库和工具列表没有组织好模型就算想帮用户也会力不从心。我有一个习惯每次调优 Agent 效果都用这三个词做一次排查清单。先看 Key 层上下文里有没有足够的企业或角色上下文。再看 Query 层用户的输入有没有经过解析和意图标准化。最后看 Value 层工具 description 是否清晰、知识库检索是否有有效结果。绝大多数效果问题都能在这三层里找到根因压根不用去盲目改温度参数。3.2 公开榜单怎么读别被数字绑架open llm leaderboard 等公开榜单今天又被频繁提起。我很理解大家选型时想用榜单量化模型能力但我必须说榜单数字只能反映“通用能力”不能完全代表你业务场景里的真实表现。原因很简单通用榜单考的科目跟你的业务题不一样。一个模型数学推理得分高不代表它在中文合同条款抽取上表现好一个模型在代码生成榜单位列前茅也不代表它能玩明白你要用的那些私有工具协议。更麻烦的是现在很多模型开发者会针对榜单测试集做优化测试数据可能已经被间接污染所以纯看排名选模型风险不小。我的建议是“榜单初筛 场景实测”。初筛时参考 open llm leaderboard 这类公开榜单没问题把候选模型缩小到三五个。之后必须拿你自己的数据、你的工具 schema、你的 prompt 模板做一轮 A/B 测试测的时候至少跑五十条真实请求对比关键指标比如任务完成率、工具调用成功率、平均轮次、token 消耗量。LLM as judge 是现在比较常用的评测手段让一个更强模型当裁判来对比回答质量但它也有偏好偏差所以我一般会把“裁判评分”和“客观可量化指标”结合起来看。这里要提醒一句今天热词里还有 llm wiki它其实是社区维护的模型信息库选型时也可以用这类聚合信息快速了解模型的上下文长度、工具调用支持程度、许可协议等关键参数比只看榜单更全面。3.3 模型应用新方向Spatial LLM 与精调实践在今天的热词里spatial llm 是一个值得留意的方向。空间 LLM 指的是具备理解空间关系能力的多模态模型它能处理“某个物体在另一个物体的左边”“从 A 点到 B 点怎么走”这一类空间推理问题。这类模型在具身智能、机器人控制、AR 导航、室内设计辅助等场景里非常有用。虽然 spatial llm 对大多数普通 Agent 开发者来说还比较前沿但它揭示了一个趋势垂直能力会越来越多地被注入通用模型。与之对应的另一条路线就是热词里的使用聊天记录模型精调llm。你可以把过去积累的优质客服对话、Agent 轨迹、工具调用记录整理成训练集对模型做监督微调效果通常比单纯调 prompt 更稳定。不过精调不是万能的它更适合让模型学会某种固定的输出格式或语气习惯不适合让模型记住大量事实性知识知识层面的补充应该靠检索增强而不是靠微调。基于llm的单元测试这个热词也值得一说。现在不少团队开始用 LLM 生成单元测试用例我会把它归类到“辅助开发工具”而不仅仅是“测试工具”。它能极大提升边界情况覆盖的效率但它的产出必须经过严格 review 和构建验证。我的态度很明确用 LLM 批量生成测试脚手架没问题但“断言是否正确”这件事不能交给它自己决定。让模型初步生成再靠 CI 跑结果再由人来补充关键断言这套流程跑下来才是可持续的。4. Agent 记忆、技能与安全这三件事必须一起设计4.1 记忆设计别忘了该忘的agent记忆是今天出现频率很高的词。大家在实践中发现一个没有记忆能力的 Agent 就像一个失忆的人每次对话都从头开始体验极差。但记忆这个事做浅了没效果做深了又会把系统拖垮。常见的记忆方案分三个层次。短期记忆通常靠上下文窗口硬塞简单直接费用高、窗口满了就得裁。长期记忆一般存在向量数据库里通过 embedding 检索把相关信息召回再拼进上下文。还有一种介于中间的“工作记忆”把当前任务的关键状态单独存成结构化数据例如任务清单、已调用的工具、已确认的约束条件。我的建议是优先做工作记忆和长期记忆的组合短期记忆只保留最近几轮对话核心信息落库检索时按相关性召回而不是一股脑全塞进去。Hermes agent 相关的讨论今天出现了好几次。从热词组合看大家关心的其实是“如何把 Hermes 这类 Agent 工具接入自己的工作流”尤其是第三人外观插件比如 obsidian、hermes agent 第三方工作台。从实操角度看我建议把记忆存储和 Agent 主体解耦。也就是说不要把记忆绑定在某一个特定客户端上而是同步到一个统一的知识库层这样你在 Obsidian 里记录的笔记、在第三方工作台里标记的想法都能被同一个 Agent 读取使用。今天还看到有人问 hermes agent 安装我的建议是先明确它的记忆数据结构再去接第三方工具否则后面每次迁移都会很痛苦。说到 agent 画图其实这是 agent 记忆和工具调用的一个典型结合场景。Agent 收到“画一张架构图”的指令后需要先从记忆里调取项目背景再调用画图工具生成 Mermaid 或 SVG最后还可以用视觉模型做一轮自校验。你看画图这个动作本身不难难的是把记忆、工具、校验串起来。4.2 Agent Skill把重复工作沉淀成技能库今天不少人搜 agent skill 教程、claude agent skills甚至还有人专门去读 claude agent skills: a first principles deep dive。这个方向非常重要我甚至认为它是 Agent 项目从“能用”到“好用”的关键。什么是 Agent Skill你可以把它理解成一组可复用的提示词模板 工具调用规则 校验逻辑的集合体。比如你的团队经常需要写周报那么可以设计一个“周报生成技能”它知道从哪里拉取本周提交记录知道按什么格式汇总知道完成后发给谁。以后任何任务只要触发这个技能Agent 就会按固定流程跑而不是每次都用自由发挥的方式去生成周报。技能库的设计要点有三个。颗粒度要合适太粗则复用性差太细则管理成本高技能之间要尽量解耦一个技能不要隐式依赖另一个技能的内部实现每个技能都要有清晰的触发条件和输出格式最好能通过少量示例做 few-shot 支撑。今天有人提到 agent skill教程我建议不要一开始就设计一套庞大的技能体系而是从三个最高频的业务场景开始沉淀跑通之后再逐渐扩展。同时一定要配上技能测试集每次底层模型升级后把技能测试集跑一遍看有没有回归这是我踩过坑后养成的习惯。4.3 Agent 安全AgentPoison 与红队视角agent安全成了今天的热词这让我有点欣慰因为很多项目是上线之后才意识到安全有多重要。今天还有一条比较硬核的agentpoison: red-teaming llm agents via poisoning memory or knowledge。这概念其实指向一个很典型的攻击路径攻击者不直接攻击模型而是污染 Agent 依赖的外部知识库或记忆存储。比如你在向量数据库里放了大量公开资料攻击者如果能在这些资料里混入少量精心构造的恶意文本当 Agent 在做检索增强时就可能把攻击者想让它执行的内容当成“可信知识”检索出来从而诱导后续工具调用做危险操作。这正是“毒化记忆”攻击的可怕之处它不针对模型的推理能力它利用的是检索阶段对来源可信度的天然信任。应对这类攻击我建议从三个方向下手。第一知识来源分级内部高可信资料库的权重远高于外部抓取内容检索召回应按来源优先级加权第二入库前清洗和过滤外购数据、社区爬取数据在入库前要做恶意内容模式检测第三敏感操作二次确认凡是 Agent 要执行删除、发送、转账、修改权限这类高风险动作都必须经过规则引擎的人工确认或二次验证。Agent 安全不是模型能力问题而是系统工程问题这与我一开始说的“工程化”判断也是一致的。作为佐证今天还有 agent 安全相关的讨论与 agent 画图结合在一起我觉得很有意思。比如让 Agent 在画图的同时检查输出内容是否包含恶意指令模板。把安全校验做成一个独立技能在多个 Agent 流程里共享调用这比在每个 Agent 里单独写死安全逻辑要可靠得多。5. 生产环境落地并发、报错与端侧部署5.1 并发问题从“能跑”到“扛得住”ai agent怎么扛并发是今天非常有价值的一个热词。不少人把 Agent demo 做出来后信心满满地要推向生产结果第一个周末就被并发问题教做人了。Agent 的并发和普通接口的并发完全不是一个量级的问题。普通接口一次请求可能两三秒就返回了而 Agent 任务是长时任务一轮流程可能要调多次模型、多次工具整体耗时常以分钟计。更麻烦的是一次 Agent 任务的生命周期里模型调用是间断发生的中间穿插着工具等待时间如果按传统的“连接数限制”思路去并发控制很容易造成昂贵的空闲占用。我实践下来比较有效的方案是三层限流。第一层入口限流按用户或令牌维度控制同时启动的 Agent 任务数防止单个用户打爆整个系统。第二层模型调用限流按模型的 RPM 和 TPM 做排队这里必须用消息队列做缓冲而不是简单同步等待。第三层工具调用限流对第三方 API 的调用频率也要做控制。做一个简单的比喻如果 Agent 是一个外卖骑手你要在三个地方控制流量一次能接多少单、同一时间去店里取餐的并发数、以及在商家门口排队的顺序。任何一层的失控都会拖垮整体。今天还有热词问到 agent anywhere其实分布式部署 Agent 时三层限流的意义会更大因为流量入口分散了但模型和工具层仍然是共享瓶颈。5.2 常见运行时错误排查从错误信息反推根因今天遇到两个典型的报错热词llm request failed: provider rejected the request schema or tool payload 和 codex无法发送消息显示更新agent沙盒以及 agent execution terminated due to error。第一个报错“provider rejected the request schema or tool payload”我实在见过太多次了。问题几乎总出在工具调用定义阶段要么你定义的 JSON Schema 和实际传入参数不一致比如声明了必填字段却没传要么模型生成工具调用的格式与 provider 要求的 OpenAI Function Calling 格式不匹配要么工具参数里混入了超长文本导致 provider 侧拒绝。排查时不要急着改模型先打开你发给 provider 的请求日志看 payload 到底长什么样重点检查 functions 结构和 type 字段这个步骤能解决八成问题。codex无法发送消息显示更新agent沙盒其实是一个环境隔离问题。当开发工具提示 agent 沙盒需要更新时通常意味着 Agent 运行环境的镜像、库版本或插件版本不一致。我遇到过类似的情况线上沙盒环境沿用旧镜像而工具函数引用了新库里的一个 API导致运行时就报错。方法也很明确把沙盒环境的更新流程做成可重复的版本管理比如用 Dockerfile 或配置管理工具固定依赖沙盒更新前先在一台测试机验证更新后立刻跑一遍工具调用回归集。agent execution terminated due to error 同样属于运行时层面问题多半是某个工具调用超时或被异常中断后没有做好回收排查时要从 Agent 循环异常分支和超时配置入手重点看 harness 层的错误处理是否有兜底重试逻辑。5.3 端侧与本地部署从 LLM Studio 到安卓端热词里安卓本地运行gguf格式llm软件支持安卓8这道题背后是大家希望在不联网的环境里也能跑 LLM。这个需求非常实际有些场景对数据隐私要求极高完全不允许把文本发送到云端那么能跑在本地设备的就需要一个能运行在设备上的推理方案。GGUF 格式是 llama.cpp 生态的标准模型格式它把权重和网络结构打包成一个文件相对便于在端侧推理。你能在很多本地推理工具比如 llama.cpp、Ollama或者部分移动端推理 App中直接加载。安卓端能运行 GGUF 模型的方案我记得 R8 之后的老设备也能跑只是你得用足够小的量化版本比如 Q4_K_M 量化后的 7B 模型内存占用大概在 5GB 左右具体还要看设备剩余内存和系统缓存策略。今天另一个热词 llm studio 其实就提供了桌面端本地模型的托管和加载能力支持加载 GGUF 和多种其他格式。它相当于一个本地模型运行基础设施虽然不是专门为安卓设计的但在桌面端做模型评测和开发调试很方便。基于rust语言ai agent 也自带一点端侧属性。Rust 的性能优势使得它很适合做需要低延迟、高并发的 Agent 运行时而且 Rust 编译出的二进制比 Python 生态更容易分发给客户端设备。如果你主要面向离线部署或边缘设备Rust 是一个值得关注的方向如果你的主要场景是快速迭代业务Python 生态的开发效率还是会更高一些。做技术选型时这两者取决于你的交付形态不要跟风。另外今天社区里有一条“支持 nsfw llm 有那些”的提问。我的观点是不要在主线项目里押注这类模型一方面大多数主流供应商的内容策略和相关合规要求都不建议你用另一方面这种需求大多可以通过系统提示词和合适的开源模型做合规约束来满足。如果你确实有特殊的文本生成诉求建议先评估好数据安全和平台要求再考虑技术实现。这一条就不展开讲了。6. 实操总结报错速查与 Agent 开发路线建议6.1 常见问题速查表我把今天日报涉及的常见问题整理成了一张速查表方便你在排查时快速定位。表格里每一行都是一线实战里很常见的现象。现象大概率原因建议排查方向llm request failed: provider rejected the request schema or tool payload工具调用 Schema 与传入参数不一致检查请求日志中的 functions 定义与实参类型codex 无法发送消息提示更新 agent 沙盒运行环境版本不一致固定沙盒镜像版本统一依赖管理agent execution terminated due to error工具调用超时或异常后未回收检查 harness 层的超时与重试逻辑Agent 输出结果不稳定上下文缺乏 Key / Query 信息用 token 三层模型检查 prompt 设计多用户并发时请求排队严重缺少模型层限流机制加消息队列和 RPM/TPM 限流Agent 执行了危险操作缺少敏感操作二次确认建立规则引擎和人工审核兜底外部数据检索到恶意内容知识库来源未分级设置来源权重和入库清洗流程本地安卓端跑模型很卡模型量化等级过高或内存不足换更低 bit 量化模型释放系统内存这张表是我实际排查时的快速路径。你可以直接把它贴在你的项目手册里遇到同类型问题时先按表的顺序逐步排除。一般来说问题定位的核心不是猜而是打开日志观察请求体和返回体这个习惯能省下大量时间。6.2 给新手的 Agent 开发学习路线今天有不少热词是 agent开发学习路线、agent学习路线说明还有大量朋友在入门口徘徊。我结合自己做过的项目整理了一条相对务实的路线供参考。第一步是先手动调用一次模型 API不引入任何框架亲眼看一次请求和返回的结构理解 token 计费、对话轮次、工具调用的基本格式。第二步是掌握一个轻量框架比如 LangGraph 或 OpenAI Agents SDK实现一个“查询数据库 生成报表”的小 Agent感受 harness 层的循环与工具注册机制。第三步是加入记忆和检索功能用向量数据库给 Agent 加长期记忆同时开始设计技能库框架。第四步是接触安全与评测搭建一套简单但有效的评测集对每次修改做回归测试同时为敏感操作加一道确认机制。第五步才是追求高并发和复杂编排这时候你对架构的理解已经足够支撑你看懂各种复杂方案了。这套路线每一步都有明确的交付物不会被无限期的理论拖延卡住。我见过太多人学习 Agent 开发第一步就陷在“哪个框架更好”的争论里其实框架思想都大同小异重要的是先跑通一条完整路径。写在最后今天日报里我最想说的一点今天刷完这么多热词最让我感慨的是 agent 安全、并发、记忆这些词终于被放到台面上了。这意味着 Agent 开发正在从“秀肌肉”变成“做实事”。所谓的 posion 攻击、provider 拒绝、沙盒环境错乱、并发打满其实都是系统走向成熟的必经之路。我个人在实操中越来越强烈的体会是Agent 项目的复杂度从来不在单一模型能力上而在那些模型之外的环节——记忆怎么回收、技能怎么复用、工具调用怎么兜底、安全策略怎么不碍事。今天日报里列出的所有热词本质上都是在回答同一个问题怎么让 Agent 成为一个可靠的基础设施而不是一个靠运气输出的玩具。如果你今天只记住一个观点我希望是这一句不要把 Agent 的一切都交给模型自由发挥兜底、约束、观测这三件事才是工程化 Agent 的护城河。下次我们再聊的时候这些热词应该又会前进一批但只要这个核心观点在你换任何框架、任何模型都不会跑偏。