做 Agent / LLM 日报这件事我坚持了大半年今天这份是 2026-09-28 的整理。筛选标准很朴素能落地、有争议、或者至少能让你少踩一个坑。翻了一圈知乎热搜和时间线今天的高频词集中在几类——Agent 框架与编排、harness 和 agent 的区别、agent 记忆与安全尤其是 AgentPoison 这类攻防研究、LLM 的 token 三元组理解、本地部署 GGUF以及一批工具链Hermes Agent、ADK、Spring AI的上手经验。这篇文章不打算复述热搜标题我会把每个话题背后的原理、常见误区和实操要点展开讲清楚适合正在做 Agent 开发、或者准备入坑大模型应用层的朋友看完可以直接拿去用。1. 今日焦点热搜词背后的四类真实需求1.1 为什么 Agent 成了大模型落地的“主战场”先说一个肉眼可见的趋势社区对“单轮对话”的讨论正在快速减少取而代之的是“多步骤任务”。你问一个模型“帮我写段代码”它回答得很好这已经是旧叙事现在的问题是“让它自己拆需求、调工具、跑命令、看结果、再决定下一步”这才是 Agent 的活。原因不难理解。纯对话模型的产值被框死在聊天窗口里而 Agent 能把 LLM 接到真实的软件系统、数据源和业务逻辑上。用一句老话说LLM 是大脑Agent 是手脚。热搜里大量出现“agent是什么”“agent开发学习路线”“agent框架”这类词说明一大批人已经意识到光会调 API 不够得学会给模型装手脚。1.2 我用一张表把今天的热搜词分了类看热搜不能只看热闹要看出需求层次。我把今天出现频率最高的词归成四类每类对应一种实际问题需求类型典型热搜词背后的问题概念扫盲agent是什么、llm是什么、llm框架新手入场需要路线图工程选型harness和agent区别、agent框架与编排、spring ai agent架构怎么设计框架怎么选安全与可靠性agent安全、agentpoison、agent execution terminated上线前怎么防翻车工具链与效率hermes agent、agent skill、基于llm的单元测试怎么把 Agent 用进日常工作流这四类不是平行的而是递进的。绝大多数人先问“是什么”然后卡在“怎么选”最后死在“怎么不出错”。我下面按这个递进顺序展开。2. 概念扫盲与学习路线先搞清楚 Agent、Harness、框架2.1 Agent 与 Workflow、Harness 的真实区别今天知乎上有个问题很典型“harness 和 agent 区别是什么”这问题问得特别好因为很多人把这三个词混着用Agent、Workflow、Harness。直接说结论。Workflow 是“写死的流程”代码决定每一步做什么LLM 只在固定节点填空。Agent 是“模型主导的决策循环”模型自己决定下一步调哪个工具、要不要停下来。Harness 是“连接层”负责把 LLM、工具、记忆、权限、上下文管理这些零件组装起来让 Agent 能在一个受控环境里跑。打一个比方Workflow 是流水线每个工位固定Agent 是自由职业者自己接活、自己选方案Harness 是那间带办公桌、网线和门禁的办公室——没有它Agent 想干活也够不着资源。今天社区里大量讨论的“llm框架”“agent编排”本质都是不同层级的 Harness 实现。这个区分不是咬文嚼字它直接决定你的架构。如果你把所有逻辑都写进 Workflow确实稳定但灵活度差如果完全交给 Agent 自由发挥质量和安全都没保障。成熟的做法是混合常规路径用 Workflow 兜底异常和复杂分支交给 Agent 决策。这就是所谓“harness 和 agent 的边界设计”。2.2 新手路线从手写 ReAct 到用框架很多人问“agent开发学习路线”我的回答一直没变过先手写一个最简 ReAct再碰框架。为啥因为框架会帮你把“思考-调用-观察”这个循环包装得严严实实你根本看不到里面发生了什么。一旦出问题你不知道是模型抽风、工具报错还是上下文被截断。手写一个最小 ReAct 其实不难核心就四步系统提示词里定义工具列表和输出格式。模型输出“我需要调用工具 X参数是 Y”。你的代码解析这个输出真的去执行工具。把工具结果拼回上下文让模型继续推理。这个循环跑通之后你对 Agent 的理解会瞬间清晰所谓 Agent本质就是“模型 循环 工具接口”。之后再上手 LangGraph、CrewAI、AutoGen、Spring AI 这些框架你就能看懂它们各自封装了什么、提供了什么额外能力状态管理、多智能体通信、持久化等。我给新人的路线是第一周手写 ReAct第二周加记忆和工具第三周挑一个框架重写第四周开始做评测和安全性测试。四周围绕记忆这一块重点看三个方向短期记忆上下文窗口内的对话、长期记忆向量库里的知识、情景记忆过去任务的经验复用。这里插一句今天热搜里的“llm的token三个点key我是谁、query我在找什么、value我能提供什么”其实就和你怎么写记忆检索逻辑直接相关这个话题我在第 3 节专门讲。2.3 框架选型别贪多先跑通一个框架选型是今天热搜里“agent框架与编排”热度最高的部分。我的建议很直接别一上来就搭全家桶。很多新手把 LangGraph 的复杂状态机、CrewAI 的多 Agent 协作、AutoGen 的对话协议全装进项目里结果项目还没跑起来先被框架自身的复杂度压垮。选框架只看两件事一是你团队的语言栈二是你的任务到底是“单 Agent 调工具”还是“多 Agent 协作”。如果是前者直接用轻量方案比如 OpenAI/Anthropic 官方的 tool calling 一个 Python asyncio 循环就够了如果是后者再去考虑带编排能力的框架。今天热搜里出现的“spring ai agent”就是 Java 生态的选择适合团队本来就在 Spring 体系里的情况ADK 则是 Google 出的一套多语言 Agent 开发套件一会儿在第 5 节展开。记住一个铁律框架是给工程化用的不是给学习用的。你手写跑通的逻辑越扎实用框架时才越知道自己到底需要框架的哪部分能力。3. 记忆与安全Agent 最容易翻车的两个地方3.1 Token 三元组Key、Query、Value 到底在说什么今天有个热词挺有意思“llm的token三个点key我是谁、query我在找什么、value我能提供什么。”第一次看到这句的人可能会懵我拆开讲。这其实不是对 token 本身的定义而是对模型内部 Attention注意力机制里 Key、Query、Value 三个向量的通俗解读。在 Transformer 里每个 token 都会生成三组向量Query 表示“我要去什么地方找信息”Key 表示“我身上带的是什么标签”Value 表示“我实际提供的内容是什么”。模型计算注意力时用 Query 去和所有 Key 做相似度匹配再按匹配权重把对应的 Value 加权求和。你可以把它类比成图书馆查资料你带着问题Query去检索图书索引Key找到匹配的书籍后抽取出书里的实际内容Value。这也是为什么“key 我是谁”这个说法不完全准确——Key 不是身份而是“这个 token 能被什么类型的问题匹配上”。但这个类比放在 RAG 和 Agent 记忆设计里特别好用你的检索器本质上就是在做一次大规模的 Key-Query 匹配被取回的 Value 会被塞进上下文。理解了这一层你就明白两个实战要点。第一不要往上下文里塞无关内容因为无关 token 的 Key 会干扰 Query 匹配拉低注意力质量第二设计记忆检索时要保证“索引文本”Key和“被检索文本”Query的语义空间一致不然查不到。很多人 RAG 效果差就是因为索引用了摘要而用户问题问的是细节两者 Key-Query 对不上。3.2 Agent 记忆怎么做短期、长期与外部知识Agent 记忆设计是今天“agent记忆”话题的核心。我的实操经验是三层分开管。短期记忆就是上下文窗口内的内容管理要点是“裁剪策略”窗口满了之后是丢最早的、还是压缩成摘要、还是把关键对话转存到长期记忆我常用的做法是分层归档——超过窗口的内容按主题生成摘要保留原始记录在外部存储里需要时再检索回来。长期记忆用向量库存两类东西一类是事实知识产品文档、业务规则另一类是经验之前任务怎么做的、踩过什么坑。检索时注意设置相似度阈值低于阈值就不返回否则模型会被一堆无关的碎片干扰。今天还有人在讨论“agent记忆是不是应该分情景记忆”我认同把“过去成功完成任务的步骤”单独存起来下次遇到同类任务直接参考能显著减少试错次数。外部记忆则是 RAG 这层对接知识库或者数据库。关键是权限不同 Agent 角色只能访问对应范围的记忆不然就会出现第 3.3 节要讲的投毒问题。3.3 AgentPoison给你的记忆库下毒今天热搜里有一条学术向的词“AgentPoison: red-teaming llm agents via poisoning memory or knowledge bases”。这条值得所有人重视因为它揭示了一个真实的攻击面Agent 的记忆和知识库是会被投毒的。原理并不复杂。Agent 在决策时会检索记忆或知识库攻击者如果能往知识库中注入恶意内容比如一段看起来像正常文档、内部却藏了指令的文本当 Agent 检索到这段内容时就可能被执行注入指令改掉原本的任务目标甚至把用户数据外传。你可能会说“我的知识库是内部文档谁能投毒”但现实中入口非常多抓取进来的网页、用户上传的附件、第三方 API 返回的内容都可能成为投毒载体。防御上我有几条具体的建议。第一检索结果必须过一层“内容校验”凡是包含指令性语言、URL、特殊标记的内容要做降权和标记第二工具调用和记忆调用要做权限分离记忆只能“给模型提供信息”不能“指示模型执行操作”第三对敏感输出做二次校验让模型自己说一遍“我接下来要做什么”再交给下游执行。这套组合拳不复杂但能挡住大多数记忆投毒攻击。3.4 一份可以直接抄的 Agent 安全清单今天“agent安全”这个热搜词下面我看到不少人在问“Agent 上线要做什么安全配置”我直接把我项目里用的清单贴出来工具调用走白名单未注册的工具一律拒绝。Agent 运行环境放沙盒禁止访问生产数据库、支付接口等敏感资源。所有工具的执行结果返回给模型前先做敏感信息过滤。审计日志记录“请求-决策-动作”三步全链路至少保留 30 天。对模型输出做约束让它输出结构化 JSON动作 参数由代码层做最终决策校验。定期清理和审计知识库凡是来源不明的文档直接下架。这六条里第五点最重要。经验是不要把“决策权”完全交给模型模型负责“提建议”代码负责“做决定”。比如模型可以建议“删除这条数据”但真正执行删除前必须有一个人类确认或者规则校验的环节。这个设计能兜住绝大部分模型幻觉和恶意注入。4. 真实环境下的实战排查并发、沙盒和工具调用4.1 AI Agent 怎么扛并发“ai agent 怎么扛并发”今天在热搜上挂了一天。我把并发问题拆成两个层面API 限流和任务调度。第一层是 LLM API 的限流。一个 Agent 任务通常要多次调用模型QPS 一上去就会被限流。解决方案很朴素信号量Semaphore控制并发数 指数退避重试 语义缓存。信号量让你的并发请求数保持在配额之内退避重试应对偶发抖动语义缓存对高频相似请求做命中能省掉一大半的模型调用。我用 Python 写过一段很简洁的控制代码import asyncio sem asyncio.Semaphore(8) # 按你的 API 配额调整 async def call_llm_with_limit(prompt: str) - str: async with sem: attempt 0 while attempt 4: try: return await llm_client.complete(prompt) except RateLimitError: await asyncio.sleep(2 ** attempt) # 1s, 2s, 4s, 8s attempt 1 raise RuntimeError(LLM 调用失败重试耗尽)第二层是任务调度。Agent 任务是长任务不能像普通接口那样同步等结果。标准做法是任务队列请求进来后先创建一个任务异步 worker 取任务执行进度写入 Redis 或数据库前端轮询状态。想水平扩容就把 worker 做成无状态的状态全部外置这样加机器就是加 worker 数量。另外还有一个很多人忽略的点并发场景下 Agent 的状态隔离。每个用户会话的上下文、工具执行结果、临时文件必须隔离否则高并发下会出现“串号”——A 用户的数据跑到 B 用户的上下文里。这种事故在 Agent 系统里比在普通 Web 系统里更容易发生因为状态散落在多个环节。4.2 Codex 无法发送消息和沙盒更新今天热搜里“codex无法发送消息”和“显示更新agent沙盒”这两条很可能是同一批人遇到的同一次故障。我在本地跑 Codex 遇到过类似问题把我的排查顺序写出来。第一步判断是不是会话状态问题。Codex 这种长会话工具会保存对话状态和沙盒文件状态过期或者文件冲突会导致“无法发送消息”。先尝试codex resetsession或者直接开一个新会话如果新会话正常说明是旧会话状态坏了。第二步检查沙盒提示。“显示更新agent沙盒”通常意味着你的沙盒环境版本和当前 Codex 版本不匹配工具要求你更新沙盒镜像或重建工作目录。按提示执行更新后重启会话一般能解决。如果你是在容器里用的 Codex注意镜像是否被清理过容器重建后沙盒目录丢失是最常见的根因。第三步排查认证和网络。token 过期、密钥轮换没同步到配置都会造成请求失败。先把认证信息刷新一遍再考虑其他原因。这里提醒一句生产环境里不要手动管理密钥用环境变量或者密钥管理服务避免密钥散落在一堆配置文件里。4.3 tool payload 被拒schema 和工具调用的坑今天那条“llm request failed: provider rejected the request schema or tool payload.”报错遇到过的人应该不少。这报错字面意思是你传给 LLM 提供商的工具定义schema或者工具调用载荷payload不符合要求。最常见的三个坑我一一说。第一个是 JSON Schema 写错。很多框架允许你直接写 Python 函数签名然后自动生成 schema但如果你手写 schema很容易犯“required 字段没写全”“type 用了 null 而不是 string”这类错误。排查办法是把你传给 provider 的原始 schema 打印出来逐个字段校验别用眼睛看直接用 JSON Schema validator。第二个坑是参数类型不匹配。模型返回的工具调用参数和你的函数实际接受的参数对不上。比如 schema 里写了number但你执行函数时用了 int 类型或者日期字符串格式解析失败。这种问题在框架层经常被静默吞掉只在最外层报个笼统错误。建议在工具执行函数入口做一层显式类型转换和校验快速暴露问题。第三个坑是 max_tokens 太小。工具调用的输出其实很占 token如果 max_tokens 设置太紧模型的工具调用结果会被截断变成非法 JSON报出各种莫名其妙的 schema 错误。我习惯在 Agent 场景把 max_tokens 放宽 20%30%给工具调用留足空间。排查顺序是先看原始报错细节再检查 schema最后查 max_tokens 和上下文长度。5. 榜单、本地部署与多语言生态5.1 公开榜单怎么读才不被带偏今天热搜里有“open llm leaderboard 等公开榜单”很多人直接把榜单排名当选模型的标准这其实很危险。公开榜单比如 LMArena 的 Elo 排名、各类 LLM Leaderboard有参考价值但盲信榜单会让你在真实任务上翻车。我的经验是三个“不看”不看总分看分项——对话、推理、代码、数学每项能力差异很大你的任务用哪个能力就看哪个分项不看单一 benchmark看多个来源交叉验证——某个榜单可能模型在训练时已经见过测试集不看太新的排名看稳定一段时间后的数据——模型频繁更新榜单数据滞后今天的第一名下周可能就不是了。更靠谱的做法是自己建评测集。挑 3050 个你业务里的真实问题让候选模型跑一遍人工打分。成本不高但比任何公开榜单都有说服力。我每次做模型选型都先跑自己的评测集再回头参考公开榜单解释差距。5.2 安卓手机本地跑 GGUF小模型也有大用处“安卓本地运行gguf格式llm软件”这条热搜说明不少人在尝试把模型跑在手机上。GGUF 是 llamacpp 家推的量化模型格式专门为了在本地 CPU/GPU 上高效推理设计的。手机上跑小模型不是图它能替代云端大模型而是图它“本地运行、数据不出设备、离线可用”这三点。对隐私敏感的场景来说这需求很真实。实操层面我建议先搞清自己手机的配置内存至少 8GB旗舰骁龙或天玑平台体验更好。模型选型上手机端跑 7B8B 的量化模型比如 Q4_K_M 级别是甜点区再大就太吃力了。App 方面现在不少安卓端支持 GGUF 的推理软件下载模型文件后直接导入就能跑聊天、摘要、本地问答都没问题。有一点要注意手机跑模型的功耗和发热很厉害长时间跑会降频建议把它定位成“有需要时用一下”而不是常驻服务。顺带说一句“agent anywhere”这个热词。手机本地模型 小 Agent 的组合确实让“随时随地的随身智能体”变得可落地了。本地小模型的 Agent 能做日历整理、笔记归档这类轻任务涉及复杂推理还是交给云端大模型。混合架构会是常态。5.3 Spring AI、ADK Kotlin、Rust Agent三种语言生态速写今天热搜里同时出现了“spring ai agent”“adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent”“基于rust语言ai agent”分别对应三种语言生态我各说一句经验。Spring AI 是 Java/Spring 生态进入 LLM 应用层的方案。它的价值在于能直接复用你团队的 Spring Boot 基础设施——配置管理、依赖注入、监控体系全是现成的。如果你的团队是 Java 背景不要犹豫用 Spring AI它对工具调用、结构化输出都有封装学习曲线比想象中平缓。ADKAgent Development Kit目前也在快速迭代。它对 Java/Kotlin 的 JVM 支持做得比较顺滑写一个最小 Agent 大概就是定义 Agent、挂工具、跑循环三件事。我试过在 JVM 上用 Kotlin 快速跑通一个带工具调用的 Agent抽象跟 Python 版基本一致差异主要在类型系统和异步模型上。Kotlin 的协程处理并发比 Python 的 asyncio 更直白Android 和微服务团队可以重点关注。Rust 写 Agent 则完全是另一个出发点性能和内存安全。在大流量生产环境里Rust 版 Agent 能扛住 Python 扛不住的并发但开发效率低。我的建议是非高并发场景别用 Rust 写业务 Agent但如果你的框架层需要极致性能用 Rust 写核心执行引擎上层业务用 Python/TypeScript 调是最务实的组合。6. 效率工具把 Agent 真正用进日常工作流6.1 Hermes Agent 与 Obsidian本地方案“hermes agent”今天在热搜里出现了好几次有人问安装、有人问“第三方工作台”。我理解大家想要的是一个能在本地把 LLM 和个人知识库比如 Obsidian 笔记库连接起来的 Agent。你是不是觉得如果 Agent 能直接读取我的笔记、回答“我上次记的关于 XX 的结论是什么”那才是真·效率工具这个方向是对的但要有心理准备本地 Agent 个人知识库本质是个小型的 RAG 项目。装好 Agent 后第一步是配置笔记库索引让它能定位你的 Obsidian vault第二步是设置权限范围明确 Agent 能读哪些目录第三步是建立检索和回答的提示词模板。装好之后的体验确实是“真香”尤其是写文章找资料的时候。6.2 Agent Skill 入门从 SKILL.md 开始“agent skill教程”也是一条热度很高的词。Anthropic 提出的 Agent Skills 设计思路我的理解是把模型需要掌握的技能做成一个标准化的文件包里面包含一份 SKILL.md技能说明、若干脚本和参考文档模型在执行任务时按需加载。这跟传统 prompt 模板最大的区别是结构化——技能包可以被版本管理、被多个 Agent 共享、被持续迭代。做一个 Skill 非常简单核心就是写 SKILL.md 文件里面写清楚这个技能什么时候用、执行步骤是什么、有哪些禁忌和最佳实践。然后把它放到 Agent 能访问到的技能目录里。我做过一个“画图”技能包把图像生成的提示词规范、工具调用参数、后处理流程都写进去之后 Agent 画图的质量明显稳定了。这个模式建议所有做 Agent 的人重视它本质上是把“经验”沉淀成了可复用的资产团队里每个人都能往技能库里贡献。6.3 LLM as Judge评测的正确姿势“llm as judge”这个概念今天也上榜了。用 LLM 当裁判给 Agent 回答打分确实是目前最常用的自动评测手段但用得不对评测结果会自欺欺人。我有四条经验。第一裁判模型不能同时是选手模型。你用一个模型既做任务又给自己打分分数必然虚高至少要换一个不同家的模型做裁判。第二打分要有评分标准rubric预先定义什么算好、什么算差让裁判按标准打分否则裁判只会凭感觉。第三注意位置偏见——多个答案摆在一起时模型往往偏好排在前面的那个所以配对比较时要随机打乱顺序。第四定期人工抽查。自动评测只是筛子人工抽 10% 的样例检查裁判打分质量防止评测体系悄悄跑偏。6.4 让 LLM 帮你写单元测试“基于llm的单元测试”这个方向已经被越来越多人验证过是真有用的。我用 LLM 写单元测试的感受是它对覆盖普通路径和边界条件很好用能快速生成大量测试用例但对“业务逻辑里暗藏的坑”无能为力——因为模型的测试来自对代码的静态理解而不是对线上故障的记忆。实操建议是让模型直接基于代码生成测试但不让它“想当然”地编造测试期望值。我的做法是给模型提供被测函数、输入输出约定、以及测试框架风格让它生成测试框架和边界用例然后我再人工补几个关键的程序能跳过的复杂断言。配套工具社区里已经有不少了有的还能自动跑测试、分析覆盖率、做失败反馈迭代。不过要提醒LLM 生成的测试也会有幻觉比如它可能断言一个根本不存在的异常类型。所以生成后的测试必须真实地跑一遍让绿了就说明这个测试至少是成立的。结尾就写到这里。今天这份日报里提到的所有问题大多是我自己在项目里真实踩过的。我做 Agent 项目最大的体会是Agent 的能力上限由模型决定但质量下限由工程决定。记忆管理、安全清单、并发控制、评测体系这些听着不如“让模型自己思考”性感但决定你的 Agent 能不能从 Demo 走向生产。如果你今天只记住一件事那就是先跑通最小循环再逐步加记忆、加安全、加评测别一上来就追求大而全。最后分享一个小技巧——把你每次排查过的报错和解决方案记下来形成一个团队内部的“问题速查表”这东西比任何教程都管用。