今天是 2026 年 9 月 28 日。如果你每天都在刷 Agent / LLM 相关的热搜会发现现在的信息流越来越像一场大型混战一边是新手在问agent 到底是什么另一边是资深开发者在讨论框架编排、并发压测和记忆持久化。我整理这份日报不是为了把热搜词复读一遍而是想从一堆标签里挑出真正值得花时间的内容并补上热搜背后被省略的背景知识。这篇整理适合三类人刚开始接触 LLM 和 Agent、想找一条清晰学习路线的初学者已经在写 tool calling、做多 Agent 编排但经常被框架和报错搞得头疼的开发者以及更关注安全、评测和模型选型的决策者。你可以把它当成 9 月 28 日这一天的信息锚点也可以把它当成一份按图索骥的操作手册。1. 今日热搜全景哪些词在真讨论哪些只是路过1.1 热搜词归类的第一眼印象我把今天的热搜词按讨论热度归了一下类差不多是这么几摊事基础概念派agent 是什么、llm 是什么、llm 模型、harness 和 agent 区别、llm 的 token 三个点、spatial llm、llm as judge、llm wiki。开发实践派agent 开发学习路线、ai agent 搭建、agent 框架、agent 架构、agent 框架与编排、ai agent 怎么扛并发、agent 记忆、agent skill 教程、基于 rust 语言 ai agent、adk.dev 的 kotlin 快速上手、spring ai agent、使用聊天记录模型精调 llm、基于 llm 的单元测试。工具落地派hermes agent 安装、hermes agent obsidian、hermes agent 第三方工作台、llm studio、安卓本地运行 gguf 格式 llm 软件支持安卓8、agent anywhere、agent 画图、pi agent、presonl agent、agent ransack。报错排坑派codex 无法发送消息显示更新 agent 沙盒、llm request failed: provider rejected the request schema or tool payload、agent execution terminated due to error。安全与评测派agent 安全、agentpoison: red-teaming llm agents via poisoning memory or knowledge base、open llm leaderboard 等公开榜单。这个分类本身就说明了问题Agent / LLM 的话题已经从这是什么过渡到了怎么用、用什么、用起来报错怎么办。真正的讨论重心在开发和落地而不是概念科普。1.2 我判断信号和噪音的三把尺子面对热搜我一般不会逐条跟风而是先过三把尺子。第一把尺子是问题有没有具体场景。llm 是什么这类是永恒的入门流量词信息增量约等于零但llm request failed: provider rejected the request schema or tool payload这种词说明有很多人卡在工具调用配置上这才是真需求。第二把尺子是关键词背后有没有可复现的结论。agent 框架与编排听起来大但如果能落到编排到底编排了什么——任务拆解、上下文传递、工具调度还是 Agent 之间的通信协议那就有得写没有落到这层就只是词藻。第三把尺子是词背后是工具还是概念。概念可以被反复解释但不会产生新的生产问题工具词往往意味着有软件要装、有环境要调、有报错要处理这才是日报的精华所在。用这三把尺子滤完今天真正值得深挖的是三条线索一是 Agent 开发从入门到工程化的完整路径二是本地部署和模型精调的使用实践三是安全与评测视角下的 Agent 可信度问题。1.3 三个被热搜反复顶上来的真问题如果你只看热搜列表会觉得大家在问几十个不同的问题。但把同义词合并后真实的问题只有三个。第一个问题Agent 和 LLM 的边界以及围绕边界出现的 harness、框架、编排这些词到底是什么关系。这是 9 月 28 日最高频的认知需求新手需要一幅地图老手也需要一套统一的说法。第二个问题在真实业务里Agent 怎么稳定地跑起来。具体表现是并发扛不住、记忆不持久、工具调用触发 schema 错误、沙盒环境失效。热搜里好几条都是报错原文这说明很多项目的进度其实卡在工程细节上而不是算法上。第三个问题Agent 到底能不能被信任。AgentPoison 这类攻击词出现在热搜里不是偶然。大家开始意识到一个能调用工具的 Agent 如果被恶意提示注入风险比单纯的大模型聊天接口大得多。后面的内容我就围绕这三个问题展开。2. 基础概念的边界LLM、Agent、Harness 与 token 三元组2.1 LLM 与 Agent 的边界到底划在哪先说 LLM。LLM 是大语言模型它本身是一个输入 token 序列、输出下一个 token 概率分布的模型。你给它一段文字它补全一段文字仅此而已。它没有外部世界的感知也没有主动行动的能力。Agent 则是在 LLM 外面包了一层循环控制。一个完整的 Agent 至少包含四部分模型、记忆、规划、工具调用。它在一个循环里不断重复读状态—思考下一步—调用工具—观察结果—再思考这个过程直到任务完成。所以最直白的一句话LLM 是 Agent 的大脑Agent 是大脑外面长出的手和脚。热搜里agent 开发和llm 模型成对出现本质就是因为大家意识到光调接口做不出产品必须把模型放进一个能行动的壳子里。这个区别也解释了为什么你会看到agent 架构和agent 框架两个词总一起出现。架构是指你的 Agent 内部模块怎么组织知识库、记忆库、工具层、规划器如何分层框架则是别人已经写好的半成品直接给你定义好了循环、消息格式和工具注册方式。2.2 Harness 和 Agent一个是壳一个是脑harness 和 agent 区别这条热搜我猜很多人是被 Agent 开发工具链里的术语绕晕了。Harness 通常翻译成运行框架或控制壳它负责的是 Agent 运行时的基础设施启动循环、管理上下文窗口、注入系统提示词、拦截工具返回结果、处理重试和错误、暴露给外部 IDE 或 CLI。Agent 本体是壳里跑的那个决策大脑它决定下一步调什么工具、基于什么记忆、生成什么回复。Harness 规定了 Agent 活动的物理边界Agent 只负责在边界内做推理。可以这么理解Harness 像是剧场舞台Agent 像是台上的演员。舞台负责灯光、音响、幕布升降演员负责表演。演员可以换舞台也可以换但一场戏要好看两者得有协议。在工程上这个区别最大的意义是当你的 Agent 出现行为问题时要先判断是脑子的决策问题还是壳的工具环境问题。比如 Codex 报无法发送消息显示更新 Agent 沙盒这就典型的壳的问题不是模型问题。很多初学者一看到这类报错就去换模型结果白忙一场。2.3 token 三元组key 我是谁、query 我在找什么、value 我能提供什么热搜里那条llm 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么特别值得展开。这不是 token 本身的分词概念而是在讲 Transformer 注意力机制的三个向量角色。在 Attention 机制里每一个 token 都会生成三个向量Query代表我正在寻找什么信息。它像一个搜索关键词决定当前 token 想关注上下文里的哪部分。Key代表我是谁也就是这个 token 有什么特征可以被别人搜索到。Value代表我能提供什么也就是一旦某个 token 被匹配上它真正输出的信息内容。如果把注意力层比作图书检索query 是你写下的索书单key 是书脊上的标签value 是书的正文。索书单先和标签做匹配匹配成功的书你翻开读正文。这个三元组模型对 Agent 开发者有什么用非常有用。你可以用同一个思维去理解 RAG 检索、记忆召回和工具选择——当 Agent 面对大量工具时它实际上是在用当前任务的 query 去匹配每个工具描述里的 key然后决定调用哪个工具执行 value。这也是为什么工具描述写不好Agent 就老是选到错误工具。把工具名称和描述当成 key 来精心设计是 Agent 工程里性价比最高的优化之一。2.4 Spatial LLM 和 LLM as Judge两个容易被误解的衍生词再扫两个热搜词。Spatial LLM空间大模型目前更多指向能理解三维空间关系、能定位和规划路径的模型典型应用是具身智能、机器人导航、AR/VR 里的空间理解。它和普通 LLM 的差别在于普通 LLM 在文字空间里推理Spatial LLM 在坐标、几何、拓扑结构组成的空间里推理。如果你不是做机器人方向这个热搜对你来说属于需要关注但不必深挖的领域。LLM as Judge 则是把大模型当打分器。比如给模型一段代码、一个回答或一个 Agent 的对话记录让模型按固定 rubric 打分。它的核心难点不是能不能打分而是分数可不可靠。今天的热搜里还有基于 llm 的单元测试这条也属于 LLM as Judge 的延伸——用模型生成测试用例、验证输出、甚至自动修复失败测试。这个方向我强烈建议多做尝试因为它是少数能立竿见影提升开发效率的用法。3. 从零到一Agent 开发路线、框架选型、并发、记忆与技能3.1 一条可复制的 Agent 开发学习路线今天agent 开发学习路线这个词的热度很高但我翻了半天也没看到一份靠谱的路线图这里我直接给一份我实践过的六步路线。第一步把 LLM 调用跑透。熟悉一套 API 的调用参数、token 计算、temperature 对输出的影响、system prompt 的作用边界。这一步的门槛很低但别跳过因为后面所有抽象都是建立在对接口的理解之上。第二步做一次带工具调用的任务。选一个国内外的模型平台让模型调用一个计算函数或者查天气的 API。核心目的是理解 tool schema 是什么、模型如何生成 tool call、结果如何回传。这一步会踩到很多 schema 相关的坑但很值。第三步用现成框架搭一个完整 Agent。比如 LangChain、LlamaIndex、Google ADK、Spring AI 这类跑通一个读知识库—回答问题—调用工具—返回结论的循环。第四步手写一个极简 Agent 循环。这是很多人没有做的一步。不用框架自己用几行代码实现 agentic loop你就会彻底明白框架替你做了多少事也会明白那些报错到底发生在哪个环节。第五步加记忆和状态。从最简单的对话历史缓存到向量库长期记忆再到结构化的摘要记忆。第六步做安全与评测。引入提示注入测试、加权限控制、做端到端评估。到了这一步才算从能跑进入能上线。这个路线不是线性的第三步和第四步可以交替。但整体顺序不要跳先理解工具调用再理解记忆最后才碰安全。否则你会被太多的抽象术语淹没。3.2 框架与编排怎么选Spring AI、ADK、自研化的取舍今天热搜同时出现了agent 框架与编排spring ai agentadk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent说明大家已经不满足于 Python 一家独大开始关心自己团队的技术栈怎么融入 Agent。先澄清编排这个词。编排不是调用多少次模型而是决定多个 Agent、多个工具、多段任务之间以什么顺序、什么条件流转。编排的核心设计点有三个任务分解策略复杂目标怎样拆成子任务是并行分派还是按 DAG 依赖执行。上下文传递方式上一个 Agent 的输出哪些进入下一个 Agent 的上下文哪些落盘成临时记忆。回退与重试机制某个子 Agent 挂了是重试三次还是降级到另一个模型还是直接终止。Spring AI 的优势在于 JVM 生态的控制力和企业级事务边界。如果你所在团队有成熟的 Spring Boot 基建直接用它接入 Agent能省掉一大堆身份认证和可观测性的对接成本。它不是功能最炫的框架但它是故障时最好排查的框架这点在团队协作里比什么都重要。ADKAgent Development Kit的 Kotlin 版本最近讨论度明显上升它允许你在 JVM 上按声明式的 graph 方式定义 Agent 流程。今天热搜里特意强调快速上手在 JVM 上跑通一个 agent我理解大家痛点在于官方示例多是 PythonKotlin 版本一旦遇到 API 差异就容易卡住。我的建议是先照着 ADK 官方仓库的 samples 目录跑通一个 hello world再动别的。ADK 的文档不多但 samples 很全别自己硬造轮子。至于自研框架我只建议在两类情况下碰一是你需要反复实验大脑驱动流程比如动态规划 actor 群体现有框架的状态管理不够透明二是团队有充分的 Rust/go 工程能力想要更小的运行时和更可控的内存占用。否则用成熟框架能省下大量调试时间。3.3 并发场景AI Agent 扛并发到底扛的是什么热搜里ai agent 怎么扛并发问得特别实在。很多人以为 Agent 扛并发就是多线程调用模型接口真做起来才发现瓶颈根本不是 GPU也不是 API 速率限制而是状态管理。一个 Agent 任务往往包含多轮工具调用每一轮都要保留上下文和中间结果。如果 100 个任务同时跑每个任务都有自己的记忆快照和工具状态那就要考虑会话上下文是放内存还是放 Redis。放内存最省事但服务一重启全丢放 Redis 要定义 key 的过期策略防止无限堆积。一个 Agent 任务是否需要在多个 worker 之间迁移。如果需要就必须把上下文序列化到外部存储并且工具调用要做幂等设计防止某一步被重试两次。工具调用本身有没有全局共享资源。比如所有 Agent 共用一个外部 API被限流了怎么办是排队还是降级。我的经验值是先做并发上限压测比如拿 50 个真实任务同时跑看超时率和错误率再针对性地做上下文存储、幂等重试、限流降级。不要凭感觉调线程数。另外如果是纯字符串形式的 Agent 循环没有长时记忆那你完全可以把它写成无状态服务用队列把任务串起来。这种伪 Agent的扛并发能力远比开着上千个带状态的 Agent 简单而且更稳定。工程里很多场景其实不需要完整 Agent只需要一个有工具调用能力的消息处理器。3.4 记忆与技能让 Agent 有干过活的样子agent 记忆是今天另一个高热度词。记忆不是数据库而是分层的。短时记忆就是当前上下文窗口Agent 在这个窗口里记得刚刚发生的对话。它的代价是 token 消耗所以要做摘要压缩把旧对话压成一段 summary 塞回上下文。长期记忆通常用向量库存按语义相似度召回历史信息。这里常见的坑是直接往向量库里塞聊天原文结果召回一堆重复内容还占满 token。正确做法是先做结构化区分事实记忆用户偏好、项目配置和事件记忆发生了什么操作分别用不同 schema 存储。claude agent skills: a first principles deep dive这个热搜是在讲 Agent Skills 类机制的本质。Skills 本质上是一组可复用的能力封装把指令、工具定义、约束条件和示例打包成一个模块Agent 按需加载。它和提示词模板的区别在于skills 是带执行逻辑的不只是纯文本。你可以开发一些高频技能比如代码审查文档生成SQL 编写助手然后在多个 Agent 之间复用。我的建议是从第一天就给工具和技能写描述并且定期更新。工具描述是 Agent 选路的 key描述模糊Agent 就瞎猜。这比优化模型本身回报更快。3.5 Rust 生态与 AI Agent 的适配问题热搜里基于 rust 语言 ai agent也出现了。Rust 在 Agent 生态里的定位很清晰内存安全、高性能、可编译成小体积二进制。适合的场景是边缘设备、资源受限环境、以及对延迟敏感的网关层。但 Rust 做 Agent 也有代价开发速度慢于 Python生态相对碎片化很多模型 SDK 只有 Python/JS 官方版Rust 版要自己找社区实现。如果你只是个人项目试试水可以接受如果是团队产线除非有明确性能和嵌入需求否则不要第一波就上 Rust。有一个折中方案核心 Agent 编排用 Python 写工具调用层用 Rust 编译成动态库通过 FFI 调用。这样既拿到性能又保留迭代速度。不过大部分项目用不到这种优化先别急着过度设计。4. 本地部署与工具链安卓 GGUF、LLM Studio、Hermes Agent 这类工具词怎么落地4.1 安卓 8 跑 GGUF老设备也有戏但别抱错期望安卓本地运行 gguf 格式 llm 软件支持安卓8这条搜索说明有人想用手机跑本地模型。GGUF 是 llama.cpp 系列支持的模型格式好处是单文件分发、量化方便直接在 CPU 上也能推理。如果你的手机是安卓 8API 26我的建议是只跑 1B 到 3B 参数的 4-bit 量化模型上下文长度控制在 2048 以内关闭一切 GPU 加速相关的开关老设备 GPU 驱动兼容性差。推理速度可能只有每秒 5-10 个 token但做翻译、摘要、本地知识问答这种短文本任务完全够用。实操上你大约需要三步找一个支持安卓 8 的推理应用很多现代应用把 minSdk 提到 26 甚至 29所以要先确认 APK 的兼容性。准备 GGUF 格式的模型文件注意挑针对 CPU 推理优化的量化版本。在应用里降低线程数防止发热降频反而更慢。最后提醒一句手机本地跑模型隐私是最大优势但性能和效果都不如云端大模型。别把它和 GPT 级别的能力对比它的定位是离线兜底和隐私保护。4.2 LLM Studio 这类本地模型管理工具怎么选llm studio这个热搜应该指的是本地模型管理/推理工具。这类工具的价值是让不熟悉命令行的用户也能完成模型下载、加载、对话测试、甚至 OpenAI 兼容 API 暴露。用本地工具管理模型时我建议优先考虑三点。第一有没有统一的模型格式转换能力。很多工具只认 GGUF/GGML有些只认原版 checkpoint换格式时容易踩坑。选一个能自动处理下载和转换的省心很多。第二是否支持多模型并行加载。同时跑 7B 和 70B 模型很占内存支持按需加载的工具远比长驻服务更实用。第三是否提供 OpenAI 兼容 API。只要一个工具能暴露/v1/chat/completions接口你本地起的服务就能被各种 Agent 框架当成背压模型使用。这个能力是本地模型真正融入开发环境的关键没有它本地模型就只是一个聊天玩具。4.3 Hermes Agent 与 Obsidian 工作台笔记库当记忆库的正确姿势hermes agent obsidianhermes agent 第三方工作台hermes agent 安装这几条热搜说明不少人在折腾把 Agent 接进 Obsidian。Obsidian 的优势是笔记本身就是 Markdown 文件天然适合作为 Agent 的文件化记忆库。一般做法是这样的Agent 通过文件系统接口读取某个仓库下的笔记把笔记拆成小块向量化之后存入记忆库Agent 回答问题时先检索这些笔记再结合当前对话上下文给出答案。我的建议是不要用太重的数据库直接用 Git 作为笔记版本管理笔记内容变化后触发索引更新。这样你的记忆库既是备份也可以用git log查看 Agent 每次回答前看到了什么排查问题时非常好用。第三方工作台的理解要提醒一下这类项目大多在快速迭代期API 不稳定安装前先看 issue 列表看有没有人报你遇到的同版本问题。社区项目的第一原则是不要假设 README 是完整的Actions 和兼容性说明很可能过时。4.4 几个工具词速扫PI Agent、Presonl、Ransack、Anywhere今天还有几个不太常见的工具词pi agent、presonl agent、agent ransack、agent anywhere。我快速扫一遍不深入展开。pi agent 和 presonl agent 这类命名大概率是某些垂直场景的 Agent 框架或产品 MVP名字容易撞车建议搜索时带上项目主页或 GitHub 仓库名别靠一个词猜。agent ransack 听起来像是做本地文件检索的 Agent 工具类似用自然语言查本地文档。这类工具的核心价值是把 RAG 搬回本地对隐私敏感场景是好事但精度通常依赖你的分块策略。agent anywhere 这一类指的是把 Agent 嵌入各种入口的形态比如浏览器侧边栏、移动端快捷指令、桌面悬浮窗。这个方向值得关注因为随时可调用是 Agent 大规模被使用的门槛之一。这些工具词的热度说明一件事Agent 应用正在快速从网页聊天框向系统级助手扩散。以后 Agent 不是你去某个网站用的服务而是你电脑里随时待命的工具。5. 三起报错复盘从沙盒过期到 Schema 被拒到 Execution Terminated5.1 Codex 报无法发送消息显示更新 Agent 沙盒先说这个报错的心路历程。你本来正安静地让 Codex 改代码突然它告诉你无法发送消息显示更新 Agent 沙盒。这个问题的本质是Codex 这类 Agent 运行时依赖一个隔离的沙盒环境沙盒里有工作目录、依赖包和运行时状态。当沙盒镜像版本更新、或者宿主机环境发生变化时两者就不匹配Agent 无法继续向沙盒发消息。这个问题和模型能力没有半点关系换模型是没用的。正确步骤是先杀掉当前会话让 Agent 重新初始化沙盒。检查是不是工作区里有残留的锁文件或临时文件比如.codex目录下的缓存清理掉再试。如果反复出现就检查是否需要升级 CLI 或沙盒组件有些报错只是版本跨度太大导致的消息格式不兼容。最后才考虑是不是网络代理或文件描述符限制这类环境问题一般会伴随其他错误日志。我在实际项目里遇到这种情况通常一分钟内就能通过重建沙盒解决。你不需要修改代码也不要用重新拉代码这种粗暴手段那只会让 Agent 从头再来。5.2 provider rejected the request schema or tool payload这句报错比上一条更常见也更值得讲。它是说你发给模型 provider 的请求里工具调用的 schema 或工具相关的 payload 不合法被服务端直接拒绝了。最常见的四个原因工具参数的 JSON Schema 不符合 OpenAPI 规范比如type缺失、required里有未定义的属性、enum给了空数组。工具名不合法。有些 provider 要求工具名只能包含字母、数字、下划线、横线不能有空格或点号。工具声明了参数但工具调用时 payload 里多传了 schema 里没有的字段。模型返回的工具调用被你在代码里改写后结构不再匹配原 schema。排查方法不是看神秘日志而是做最小化对照先用一个最简单的只有加法函数的工具跑一次确认链路通再把你实际报错的工具 schema 打印出来和 OpenAI 风格的工具定义格式逐项比对。这里给一段常见的工具定义示例你就知道大概长什么样{ type: function, function: { name: get_weather, description: 查询指定城市当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } }把 description 里的非 ASCII 符号也检查一遍有些 provider 对 prompt 内的特殊字符有严格限制。这类报错 90% 是手写 schema 时漏了个字段剩下的才是文档理解偏差。5.3 agent execution terminated due to error这句话比前两个更笼统它可能是框架里任何一步抛了未捕获异常导致整个执行链终止。最常见的位置是工具调用返回了非预期结构、JSON 解析失败、模型输出不完整导致上下文截断、或者某个 sub-agent 超过最大重试次数。我的排查套路是三步打开 debug 日志找到最后一个成功执行的事件点。事件点之前的输出都是可信的之后的就是断点。检查终止的那一步是外部工具错误还是内部逻辑错误。外部工具比如 API 突然返回 429属于限流或超时内部逻辑则大多是代码里处理返回值的分支不完备。给 Agent 循环加上步骤级兜底。最简单的方式是在每个工具调用外面包一个 try-except把异常转成一条工具返回消息让 Agent 能看到错误并有机会自我纠正。这个技巧能救回大量本来会直接 terminated 的任务。如果你用的是框架还要注意框架自带的 agent loop 是否对单步错误设置了快速失败(fail-fast)策略。有些框架默认任何一步出错就终止整个任务这种设计在展示 Demo 时很安全但生产环境就得配降级或重试策略。5.4 一套通用的排查顺序把今天三个报错放到一起其实可以总结出一套通用的排查顺序。先做隔离判断报错发生在模型调用层、工具执行层、还是外部环境层。模型调用层看请求 payload 和返回状态工具执行层看日志里的工具名和入参外部环境层看网络、沙盒、依赖版本。再做最小复现不要带着完整业务逻辑去调试造一个最小用例。传一个固定输入调用一个工具看能不能稳定复现。如果最小用例没问题大概率是你的业务数据里某些边界值引发了问题。最后做状态归零清缓存、重启进程、重建沙盒。很多 Agent 相关报错是状态不一致导致的进程重启能解决掉其中一半。这条顺序本身不复杂但它帮你节省的是瞎试的时间。我自己见过太多人遇到 schema 错误就重装整个框架结果环境变量丢了反而多出一堆新问题。6. 安全、评估与榜单AgentPoison、Agent 安全和公开榜单的正确读法6.1 AgentPoison知识库投毒如何影响 Agent 决策今天热搜里出现了一个很硬核的词agentpoison: red-teaming llm agents via poisoning memory or knowledge base。这是一个安全方向的攻击方法思路是攻击者不直接攻破模型而是想办法往 Agent 使用的记忆库或知识库里注入带有恶意引导的样本。原理是这样的。Agent 在做决策时可能会检索知识库里的几段相关内容作为上下文交给 LLM。如果攻击者预先埋入一些表面上是正样本、实际包含特定触发器指令的文本那么在正常对话触发到相关关键词时Agent 就会被诱导执行攻击者想让它做的事比如把用户导向钓鱼网站或者泄露某个环境变量。这不是科幻场景而是已经在论文里验证过的 red team 方法。对我这种做 Agent 工程的人来说它的直接启示是没有经过访问控制的知识库就是 Agent 的攻击面。不要盲目往知识库里放网上爬来的长文本尤其是那些带过多指令式措辞的段落。Agent 的知识库检索结果不应直接用作可信指令要做来源标注、内容审核、前后端隔离。Agent 安全最怕的不是没有防护而是以为不需要防护。6.2 Agent 安全的基本盘权限最小化与人在回路普通应用安全是防外部攻击Agent 安全还多了一个特殊维度模型幻觉和提示注入会不会导致操作被恶意利用。因为 Agent 会调工具所以一旦被注入破坏力可能远超普通聊天。我今天给 Agent 项目做安全现状检查必查四项工具权限是不是最小化了。Agent 不应该拥有全局读写权限每个工具都只给它完成任务所需的最小 scope。敏感操作有没有加 human-in-loop。删除、转账、改权限这一类动作应该让 Agent 只能生成待确认请求由人工确认后再执行。外部内容有没有做边界隔离。网页抓取、邮件读取、文档上传等外部输入一律视为不可信数据提示词里要明确下方内容是不可信外部输入不能作为指令执行。有没有评估提示注入的测试集。平时就准备几十条攻击 prompt每次改完系统提示词或模型版本先跑一遍攻击测试。其中第 3 点尤其重要。很多 Agent 框架把外部内容直接拼进上下文等于把攻击文本和系统指令放在同一个平面上。正确的做法是把外部内容放在一个标记明确的不可信区块里并在区块外写明约束规则。6.3 公开榜单怎么读别只盯着分数排名热搜里有open llm leaderboard 等公开榜单这个我几乎每次都要提醒榜单分数只是弱参考不是选模型依据。当前的模型评测主要有两类一类是基于固定 benchmark 的自动评测比如 MMLU、HumanEval 这类测的是模型在标准任务上的静态能力另一类是人类偏好排行比如聊天竞技场式的胜负投票测的是真实对话体验。读榜单至少要确认四件事评测任务和你的场景是否一致。你主要做代码补全却去看一个主要测百科知识的榜单那分数对你没有参考意义。数据有没有污染的可能。很多模型在训练时就把 benchmark 的公开题目看过了刷分容易实际能力未必匹配。分数的方差大不大。有些榜单纯粹比小数点后第二位随机性还没有被多次评测均掉。近期榜单版本有没有更新过任务集。旧的 leaderboard 随着模型升级会过时要用最新版本。对要实战落地的团队我更推荐自建小评测集挑 50 条你业务里的真实输入让候选模型跑一遍人工给分。这个私有榜比任何公开榜单都有价值因为它直接反映你的场景。6.4 基于聊天记录精调与 LLM 单元测试让私有数据产生复利使用聊天记录模型精调 llm这条热搜背后是很多团队在存量数据上做二次开发的需求。用聊天记录精调核心思路是把你过去质量较高的问答对或任务执行日志整理成 (instruction, response) 数据集对模型做监督微调。这样做比单纯堆 prompt 更稳因为它是把业务风格直接融进模型参数里。精调时我给三个提醒数据清洗比模型参数更重要。聊天记录里有大量低质量回复、错误信息、重复内容要先去噪否则模型会把错误也学会。注意数据不平衡。用户会话里往往是寒暄占多数真实业务指令占少数。要按任务类型做采样保持数据分布均匀。精调之后一定要做评估集回归。不要只看 loss 下降要拿一批业务里最难的问题过一遍确认没有劣化。基于 llm 的单元测试这条也是今天的实用热点。它的价值不在于完全代替人工写测试而在于给 Agent 链路提供快速的断言层。比如你有一个文档解析 Agent可以让 LLM 判断解析结果里的字段是否齐全、是否符合某种格式作为回归测试的自动检查器。这种用法成本低、见效快值得加入日常开发流程。7. 把今天的内容落到手上值得动手的几件事7.1 今天就能做的三件事第一给 Agent 环境做一次状态清理。如果你代码里还留着让人一头雾水的报错先按第 5 章的排查顺序过一遍把沙盒、schema、重试策略整理清楚。第二把你现有工具的描述文档重新写一版。用 key/query/value 的思路给每个工具写清楚它是什么、在什么场景被调用、它能返回什么。这一步不需要改代码但往往能显著提升 Agent 的 tool calling 准确率。第三建一份最小安全清单。检查你的 Agent 有没有执行删除类操作、有没有读取外部 URL、外部内容有没有做隔离。没有的话赶紧加上。7.2 本周可以规划的进阶方向挑一个你真正会用到的场景比如代码审查、文档问答或单元测试生成用本地模型跑通一遍Agent 工具调用的闭环。不用追求大模型先解决能不能跑通。然后把你手头已有的优质聊天记录整理出一小批精调数据集哪怕只有两三百条也足以让你理解精调的完整流程。这一步是让私有数据产生复利的关键。最后关注一下 ADK 这类支持 JVM 的 Agent 框架在你的主力服务里用它跑一个真实业务任务别只停留在 hello world。7.3 一点个人的真实体会做 Agent 开发这么久我最大的体会是这个领域的门槛从来不是模型能力而是工程能力。你可以通过 Prompt 工程作弊但扛不住并发、理不清工具协议、防不住提示注入Agent 就只能停留在实验室。今天热搜里那些报错原文恰恰是行业正在走向工程成熟化的证据——大家开始关心稳定性和安全而不是只晒 Demo。保持这个状态从每天的信息洪流里抽出真正能落地的线索半年后你会发现自己已经把大多数人甩在了后面。这份日报如果能帮你少踩几个坑就算没白写。