今天这份 Agent / LLM 精选日报我不想一上来就铺新闻先聊一个更值得注意的信号社区讨论的主旋律已经从“模型多大、多聪明”整体转向了“Agent 怎么落地、怎么安全、怎么测试”。上午我刷了一圈 9 月 28 日相关的热搜词Agent 安全、Agent Skill、LLM-as-Judge、GGUF 本地部署这些词反复出现说明工具链正在进入工程化阶段。这篇文章会把今天讨论度最高的几个方向拆开讲投毒攻击与防护、开发框架与学习路线、Skills 生态、评测偏差、工程排雷以及测试与数据工程。无论你是刚开始看 Agent 的新手还是已经在写多智能体系统的老手都能找到可以立刻拿去用的内容。1. 今日头条Agent 安全进入红队阶段投毒攻击不再是纸上谈兵今天热词榜上最值得停下来细说的不是某个新模型而是“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”这条。名字很学术但底层思想并不复杂与其费劲绕过模型的安全对齐不如直接在 Agent 的记忆库和知识库里埋雷。这几年大家把注意力都放在 prompt injection 上忽视了另一条更容易被利用的路径——数据源污染。Agent 和普通聊天机器人最大的不同在于它会检索、会记忆、会调用工具这就让攻击面从“单次对话”扩大到了“整个知识生命周期”。1.1 投毒为什么对 Agent 特别有效普通问答模型只对单个 prompt 负责你问一句它答一句攻击者顶多通过输入文本里藏指令来影响单轮回答。Agent 则完全不同它内部有一个决策闭环接收用户请求、拆解任务、检索知识库或记忆库补充上下文、规划行动计划、调用外部工具、根据返回结果继续决策。在这个闭环里“检索结果”会被模型当作可信事实直接采纳。攻击者只需要让一段恶意文本进入这个库——比如通过导入一篇伪装成技术文档的网页、一份带恶意指令的 PDF、或者一段被污染的聊天历史——等到 Agent 在某个任务中检索到它这段文本里的指令就会跟随上下文一起被模型接受进而触发工具调用。这个机制和 prompt injection 有本质区别prompt injection 是“用户输入里面藏指令”投毒攻击是“内容源里面藏指令”。后者的传播链条更长隐蔽性也更强因为从 Agent 外部看检索出来的结果只是一条普通的知识片段没有任何异常特征。从红队视角看Agent 系统的攻击面比大多数人想象的要大得多。文档导入是第一个入口凡是 RAG 库接入的外部内容包括网页、PDF、Notion 文档、邮件归档只要来源没有被验证都可能带毒。对话历史的回溯是第二个入口很多 Agent 会把历史对话压缩成长期记忆如果某一轮对话本身被注入过指令后续的所有会话都会持续受到影响。工具返回的数据是第三个入口外部 API 的返回结果会回填到上下文如果 API 被劫持或返回了恶意内容就相当于通过工具间接投毒。团队共享知识库是第四个入口只要组织里有一个成员被钓鱼污染的内容就会扩散到所有使用该知识库的 Agent。1.2 红队视角下的攻击面与防御清单结合我自己做 Agent 工程的实操经验防御不能只靠提示词要分层做。我的习惯是按照四个层级来设计检索结果做指令识别在检索出来的文本进入模型上下文之前先用规则或轻量模型扫描一遍识别“当用户说某某时请执行某某”这类命令式句式对高风险的指令文本进行剥离或置灰。工具调用加确认与权限控制尤其是写操作类工具比如发邮件、写数据库、删除文件必须设置审批门槛。Agent 可以执行但高危操作要有二次确认或独立权限校验。建立来源标签体系给知识库里的每条内容打上可信度来源标签低信任来源的检索结果降权或者只允许在特定场景下使用。定期红队测试把投毒攻击用例沉淀成一个回归测试集每次知识库结构升级或模型更换后都跑一遍。安全这个东西做在架构期成本最低。等到 Agent 已经上线、用户数据已经流经系统再回头补安全就是事故驱动的改造了代价完全不是一个量级。今天热词里有“智能体自主容错控制”和“agent安全”这两条同时出现说明社区已经意识到可靠和安全是 Agent 能不能被信任的两条腿缺一条都走不远。2. 从“会聊天”到“会干活”Agent 开发路线与框架选型思路今天的热词里关于入门和选型的词扎堆出现agent开发、agent学习路线、agent框架与编排、harness和agent区别、agent架构。这种密集程度说明团队正在大规模布局 Agent但很多人卡在了概念层。我也经常收到类似提问框架那么多到底先学哪个回答这个问题之前得先把概念理清楚因为概念不清导致的技术债最难还。2.1 先分清四件套Agent、Harness、Tool、Skill新同学一上来最容易混淆的就是 Agent 和 Harness今天“harness和agent区别”也榜上有名。我直接给一个简单的划分表后面所有框架讨论都基于这四层概念定位类比典型内容Agent负责决策的主体员工本人ReAct 循环、Plan-and-Execute 策略Harness运行 Agent 的容器与宿主工位与工牌上下文管理、重试、暂停与恢复Tool可执行的具体动作手上的螺丝刀搜索、计算器、发邮件Skill面向任务的技能包标准作业流程网页存 Markdown、画图、整理笔记Agent 是“会想”的部分它决定下一步做什么Harness 是“保证能跑完”的部分它处理模型调用循环、token 预算、错误恢复、工具调用的参数校验。很多人搭 Agent 只写了一个 Agent 类却没有 Harness导致一次工具调用抛出异常就全线崩溃或者上下文膨胀后无人清理。这些其实都是 Harness 层该管的活。Tool 和 Skill 的区别也很重要。Tool 是原子动作比如“搜索网页”“计算两个数之和”Skill 是围绕一个目标组织起来的动作组合比如“把网页保存成 Markdown”这个 Skill 内部可能要调用抓取、正文提取、格式转换、文件写入四个 Tool。理解了这个分层后续学习框架时就不会被各种抽象术语绕晕。2.2 学习路线与框架选型建议我给一份按阶段推进的学习路线时间上弹性处理适合大部分有 Python 基础的人第一阶段跑通单 Agent 闭环。不引入任何框架直接调 LLM API手动维护消息序列写出一个最简的 ReAct 循环模型输出意图代码解析意图并调用工具把工具结果拼回上下文再交给模型决策。第二阶段加 RAG 记忆。用向量库存文档把检索结果注入上下文观察检索内容对模型决策的影响。这个阶段要特别注意我前面讲的投毒风险养成对入库内容做来源标记的习惯。第三阶段研究一个成熟框架。LangGraph、AutoGen、CrewAI 这类都可以重点不是学会 API而是看它把编排逻辑放在哪里、状态怎么管理、错误怎么传播。第四阶段尝试多 Agent 协作。重点关注信息如何在多个 Agent 之间传递有没有出现“上下文串味”有没有出现重复劳动。选型上我的观点比较明确早期项目优先选“少魔法”的框架即你能看到每一步数据流向的那种生产系统更看重可观测性、重试机制和状态恢复能力。今天热词里“基于 rust 语言 ai agent”也有好几条上榜Rust 写 Agent 的优势在于内存安全和并发模型编译成 WASM 之后还能嵌入移动端或边缘设备。如果你的 Agent 要跑在不同平台上“agent anywhere”这类部署思路会越来越重要——同一套能力在不同端侧复用不要为每个平台重写逻辑。另外今天榜单上还零星出现了一些新的 Agent 项目名字五花八门但趋势倒是很一致都在想办法把 Agent 嵌入到具体的工作流里而不是做成一个孤立的聊天框。3. Skills 生态爆发Hermes、Claude Skills 与“把网页存成 Markdown”的启发今天热词里 skill 相关的占了一大块agent skill教程、agent tool agent skills、claude agent skills: a first principles deep dive、hermes agent、hermes agent obsidian、agent将网页保存成markdown的skill。这让我挺兴奋的因为 Skill 作为继 Tool 之后的新抽象层正在被社区快速接受。我甚至觉得Skill 是 Agent 从“玩具”走向“生产力工具”的关键台阶。3.1 Skill 到底解决了什么问题在纯 Tool 时代每个 Agent 要自己临时编排工具调用顺序模型每次都要“临场发挥”步骤稍微多一点就很容易遗漏或顺序错乱。Skill 则把一串工具调用、判断逻辑和参数规则打包成一个可以反复使用的单元。Claude 那篇第一性原理文章的核心论点我很认同Skill 不是额外的代码而是“给 Agent 的一份可重复执行的说明书”它告诉模型在什么场景下、按什么顺序、用什么参数去调用工具。这样既避免了一次次重新发明轮子也让行为更加稳定可预期。社区里讨论度很高的 Hermes Agent 也契合这个方向它把 Agent 工作台做进了笔记场景和 Obsidian 联动频繁。为什么偏偏是 Obsidian因为笔记库本身就是天然的知识检索场景加上 Agent 之后记笔记、整理文献、沉淀卡片这些动作都可以自动化。这也解释了为什么很多人搜索“hermes agent 安装”和“hermes agent 第三方工作台”——大家真正想要的是把 Agent 嵌进自己的日常工具流而不是再多开一个网页。类似的逻辑也适用于 Obsidian 类场景大多数人不需要一个独立的 Agent 产品需要的是一个能住在自己笔记系统里的“整理助手”。3.2 从零做一个“网页保存为 Markdown”的 Skill“agent将网页保存成markdown的skill”这个热词太典型了我拿它当例子拆解一个 Skill 的完整构成。假设我们要给 Agent 配一个这样的技能它的声明大概长这样name: save_page_as_markdown description: 抓取指定网页正文并转换为干净的 Markdown 文件 trigger: 用户提供网址并要求保存为 Markdown tools: - fetch_html - extract_main_content - html_to_markdown steps: - fetch_html() - extract_main_content() - convert_and_save() constraints: - 忽略导航、广告、评论区节点 - 输出文件名规则: [网页标题].md代码之外实操里有三个细节很容易踩坑。第一正文提取不能只看 HTML 标签很多网页有懒加载机制需要等正文渲染后再抓否则存下来的是一堆空壳。第二Markdown 转换后要保留图片的本地路径映射否则文档换设备就显示不了图。第三转换结果建议先输出一个预览让用户确认后再写盘减少误操作。类似“agent画图”这类 Skill 也一样关键在于把流程参数化——画什么风格、输出什么尺寸、用哪个模型都写入 Skill 声明里而不是让模型每次猜测。我自己的习惯是每个 Skill 必须自带一个最小测试集比如三五种典型网页结构博客、新闻、文档站这个 Skill 的回归测试就跑这三个案例。Skill 生态刚起来质量参差不齐多做验证不会吃亏。另外Skill 的版本管理值得提前规划Skill 的行为会随着底层模型升级而变化没有版本记录你根本不知道哪次改动导致了行为漂移。4. 当 LLM 开始评判 LLM“裁判模型”的元评论残留与 Spatial LLM 信号今天还有一批热词集中在评测和模型能力上llm as judge、llm元评论残留、spatial llm、llm框架、llm studio。评测这个话题在 Agent 工程里越来越重要因为 Agent 的输出不是单轮文本而是一长串行动结果人工评估成本直线上升。LLM-as-Judge 成了很多团队的默认选择但它本身远非完美今天的热词里就有一条很精准地指出了问题。4.1 LLM-as-Judge 的死穴元评论残留很多人用开源模型当裁判给模型回答打分。LLM 作为裁判有几个著名的偏差偏好更长更详细的答案、偏好符合自己写作风格的答案、以及位置偏差——排在前面的答案分更高。今天社区里“llm元评论残留”这个词我理解下来是这样一个现象裁判模型在输出评分时如果带了自由文本评论它自己的点评语气会被当成“更聪明的表达方式”于是那些模仿裁判点评语气的回答反而得分更高。这个偏差在 Agent 场景里更加要命。Agent 的中间步骤输出会被裁判读成“思路清晰”但实际工具调用结果并不好——裁判只看了文本没有验证动作的有效性。我现在的对策是偏差类型具体表现缓解手段冗长偏好答案越长分越高限定最大长度后再评分风格偏好更像裁判语气的回答分更高禁止自由文本评论只输出结构化分数位置偏差排在前面的答案分更高随机打乱顺序多次采样取中位数自我偏好与裁判自身观点一致的答案分更高引入多个不同模型投票我的具体建议是评分输出尽量结构化只返回数值和几个固定维度的标签不要给自由评论每次评估做多次采样取中位数而不是平均值因为离群值常常来自裁判模型的状态波动如果确实需要了解裁判的打分理由把理由放在独立字段离线分析不让理由参与实时决策。4.2 Spatial LLM向空间理解进发“spatial llm”是今天另一个让我眼前一亮的热词。空间理解对 Agent 的意义被很多人低估了。你现在可以让 LLM 写代码、做摘要但如果你让它“帮我把客厅里那张矮桌往窗边挪半米不要挡住落地灯”传统模型会犯迷糊——这中间涉及物体位置、朝向、遮挡关系。Spatial LLM 的目标就是补上这一块。落地场景很广机器人操作需要判断物体的抓取姿态和避障路径AR 助手需要理解用户视野里的真实空间关系地图导航 Agent 需要把自然语言指令映射到路网坐标。这些都不是简单地“会看图”就能解决的需要模型在推理时保持对空间坐标、相对方向和尺度关系的持续追踪。我甚至观察到热词里还混着基础工具词比如llm studio、llm wiki。这说明社区正在把评测、调试和文档沉淀成标准基础设施工具化程度比以前高了一个量级。在这种节奏下谁先把空间理解的能力评估标准做出来谁就能在下一波 Agent 能力的竞争中占住位置。5. 今日份工程排雷Schema 拒绝、执行中断与安卓本地跑 GGUF今天的热词里出现了两条工程味道很重的报错“llm request failed: provider rejected the request schema or tool payload.”和“agent execution terminated due to error.”。这两条能上热词说明今天有很多人在同类型问题上卡住了。我分别说一下排查思路顺便聊聊“安卓本地运行gguf格式llm软件 支持安卓8”这条同样接地气的热词。5.1 provider rejected the request schema or tool payload工具定义不匹配这个报错的字面意思很明确模型供应商拒绝了你请求里的工具调用 Schema。最常见的根因有三个。第一tools 参数格式不对。有的供应商接口要求字段叫 tools有的要求叫 functions内层结构还分为 strict 和 loose 两种模式混用必炸。第二参数嵌套错误。工具声明里的 parameters 是一个 JSON Schema很多人把示例值直接塞进 schema或者把 required 字段漏掉导致校验不过。第三payload 过大。工具描述写得过长把上下文窗口撑爆请求直接被拒。排查链路我总结为四步先打印出最终发给供应商的完整请求体对照官方文档逐字段检查然后一次性简化工具描述只保留必要字段排除 payload 过大因素接着用最小复现——一个工具加一个固定问题——跑通后再逐步加回其他工具最后做一次格式回归把工具参数从示例值改成 schema 定义同步修正嵌套层级。这个报错本质上不是模型问题是你和供应商之间的“接口契约”没对齐属于最容易在框架封装层被隐藏的那类错误。5.2 agent execution terminated due to error编排层的问题居多这条报错看起来像是模型崩了但根据我的实战经验绝大多数发生在编排层。按概率排列的根因是这样工具函数抛了未捕获异常Agent 主循环没有 catch直接终止。上下文超限中间步骤太长导致下次请求被截断。重试次数耗尽某个不稳定 API 连续失败。状态不一致比如 Agent 已经执行完工具但 harness 没有更新消息状态下一步决策拿到的还是旧数据。处理思路不复杂给所有工具调用包一层统一异常处理任何异常都转成可读的消息返回给 Agent每次工具返回后打结构化日志记录调用者、耗时、返回摘要、剩余 token把 Agent 的中间状态序列化下来做到断点续跑。最近热词里那条“智能体自主容错控制”其实就是在说这一类事情——可靠的 Agent 系统不是不犯错而是能在出错后自检、恢复而不是静默终止。5.3 安卓8本地跑 GGUF量化与内存的现实问题“安卓本地运行gguf格式llm软件 支持安卓8”这条热词很有代表性说明端侧推理的需求已经非常实际了。GGUF 是 llama.cpp 生态的模型量化格式优势是单文件、便于分发一个模型文件复制到手机就能跑。在安卓 8 上跑我有几条实测经验老设备优先选 4-bit 量化比如 Q4_K_M7B 模型在 8GB 内存的手机上勉强可用6GB 内存建议跑 3B 级别。注意 APK 的 SDK 兼容性安卓 8 对应 SDK 26很多新版本 App 要求更高的 minSdk需要找历史版本或者自己编译。Termux 里跑 llama.cpp 是一个高性价比的路径不依赖特定图形界面 App升级也比较灵活。本地推理的现实价值就两条隐私和离线可用。数据不出设备对很多业务场景是硬需求。但要提个醒老手机跑小模型做文本补全还可以长上下文还是会明显发热速度下降得很快。这是端侧算力的物理约束别期待太高合理的方式是用本地模型做隐私相关的预处理、摘要、路由判断重活仍然交给远程大模型。安不安全是控制策略问题地不本地是性能成本问题两者别混在一起谈。6. 数据与测试基于 LLM 的单元测试、聊天记录精调与 Agent 记忆今天另一组热词指向了工程配套“基于llm的单元测试”、“使用聊天记录模型精调llm”、“agent记忆”。这些属于“让 Agent 可靠运行”的基础设施看起来不性感但没有它们Agent 永远只能在 demo 阶段打转。6.1 让 LLM 自己写单元测试“基于 LLM 的单元测试”并不是让 LLM 输出测试代码这么简单我实践下来有两个高价值方向。第一个方向让 LLM 根据函数签名和自然语言需求生成覆盖边界情况的样例尤其是工具函数的输入输出契约。模型能帮你找到很多你不会写的异常输入组合比如空字符串、超大数值、非法编码这些恰恰是 Agent 在真实运行中最容易碰到的情况。第二个方向更有意思用 LLM 做“行为回归”。给 Agent 相同的输入让 LLM 判断输出行为是否偏离基线。这对 Skill 升级、模型替换后的回归测试特别有用。举例来说如果你的 Skill 是“网页保存成 Markdown”升级底层模型后抓取行为是否变了、正文提取是否仍然干净用 LLM 对比新旧输出效率很高。一个最小示例def add_tool(a: int, b: int) - int: return a b # 让 LLM 生成边界测试 prompt 函数签名add_tool(a:int, b:int) - int 请给出测试用例覆盖整数边界每行一个 (a, b, expected)。 这种用法对工具层的鲁棒性提升立竿见影。我的体会是LLM 生成的测试可能不完美但它能快速扩大覆盖面把人工从“写测试”里解放出来去做更重要的测试设计。6.2 聊天记录怎么变成精调数据“使用聊天记录模型精调llm”这条热词背后是大家对对话数据的需求正在增长。我的核心建议是不是所有聊天记录都能直接拿来精调清洗比数量重要一百倍。去隐私去掉人名、邮箱、手机号、内部系统标识。这一步不能省哪怕少一半数据也要做。去噪声轮次删除中断语句、无意义问候、系统错误产生的不完整对话。构造标准会话结构把多轮对话整理成 system-user-assistant 的规范格式如果原对话里有工具调用要把工具消息单独标记出来。质量控制几百条高质量样本往往比几万条弱相关数据效果好很多精调的目标是“学会一种固定交互模式”而不是“背下所有对话”。顺带提醒一句精调不是万能的。如果只是想让模型会用某个工具先试 Few-shot 和 Skill精调适合的是固定交互模式的规模化复制。测试显示在工具调用场景里精心设计的 Few-shot 和 Skill 声明带来的提升很多时候并不比精调差而且成本低得多。6.3 Agent 记忆长期记忆库的分寸“agent记忆”这个热词代表了 Agent 能力边界的关键一环。我倾向于把记忆分成两层短期记忆等于当前对话窗口模型可以直接看到长期记忆要显式写入记忆库可以是向量库或结构化存储在需要时检索回上下文。写入策略很重要什么都存等于什么都没存。我现在的推荐是“事件驱动写入”只有满足以下条件的才落库——对后续任务有复用价值、信息密度高、可被稳定检索。比如用户明确表达过的偏好、某个项目的关键决策、某次排错的经验总结这些值得记而“今天天气不错”这类寒暄就没必要占用记忆库。记忆库本质上就是一个可供检索的知识源所以它也能被攻击者利用这正是我开头讲投毒攻击时的重点。入库内容的来源可信度必须被跟踪至少要记录“这条记忆是用户主动告诉我的还是从某次工具调用里推断出来的”。用来源标签来区分信任级别既能提升记忆检索的质量也能降低数据污染的风险。最后再分享一个小习惯。我每天整理这类精选日报时都会把当天遇到的新报错和搜索热词里出现的报错信息存进一个“排雷笔记”过一两周回头翻很多早期的认知错误都在里面。技术选型和框架可以慢慢学但安全、测试、数据这些“地基”类问题越早重视后面越省事。希望这期日报能给你带来一点可落地的启发。