整理这份日报的时候后台收到的搜索词里Agent和LLM几乎各占半壁江山。有人问框架选型有人在排查报错有人在研究记忆库投毒的论文也有人折腾安卓8老手机跑GGUF。我把这些问题按热度排了个序挑出今天最值得看的几条按“安全研究、框架工具、可靠性工程、模型部署、新词速记”五个模块展开。适合正在做Agent落地的工程师翻一翻也适合刚入坑的同学当索引用。1. 今日焦点两条值得读的深水区内容每天热词里都会混进来几篇硬核论文和几个被反复讨论的方法论。今天最值得花时间的是两条一条是AgentPoison的越狱攻击路线另一条是LLM as Judge的工程化分歧。1.1 AgentPoison通过污染记忆库/知识库对Agent做红队测试今天热词里出现了一篇标题很长的论文AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases。我建议所有做Agent安全、做RAG落地的人认真读一遍。这篇论文攻击的不是LLM本身的权重而是Agent的记忆模块和知识库。攻击者不需要改模型只需要在Agent会检索到的知识库里埋入少量精心构造的文本片段。当Agent在执行任务时检索到这些片段会把有毒内容当作可信上下文吸收进而被诱导执行攻击者预设的行为。整个过程甚至不需要直接跟Agent对话属于一种“被动触发”的攻击方式比传统提示注入更隐蔽。论文里更值得警惕的一个结论是攻击成功率对有毒样本数量非常敏感作者在多个主流Agent基准上做了测试少量毒样本就能显著提升攻击成功率同时尽量不影响Agent在正常问题上的表现。这意味着什么意味着“只要知识库可写Agent就不可信”不是危言耸听。凡是开放了知识库写入接口、允许用户上传文档再被其他用户检索的Agent应用都暴露在这个攻击面里。防御层面论文给出了一些思路我补充一点工程上能立刻做的事知识源分级把用户上传内容、官方文档、网络检索结果分池存储不同来源设置不同信任等级Agent在处理时需要感知来源权重。检索结果二次过滤不要直接拿top-k片段喂给模型先做一轮“是否与当前任务相关”的轻量校验甚至用另一个模型交叉判断。行为审计对Agent的关键行为调用工具、读取文件、发送消息做日志留痕出现异常指令时能回溯到是哪条知识片段触发的。我把这条放在今日焦点是因为它说明Agent安全的重心正在从“提示层”往“记忆层”迁移。你的Agent可以没有漏洞但你的知识库可以是突破口。1.2 LLM as Judge从玩具到工程化还差几步“LLM as Judge”今天也上了热词。这个概念本身不新就是用大模型当裁判给生成结果打分或者做对比排序替代一部分人工评测。现在几乎所有Agent项目的评估环节都在往这个方向靠因为它便宜、快、可批量。但工程化之后问题比想象中多。我自己踩过的坑有三个先说结论位置偏差两个答案谁先出现会影响裁判的判断。A/B顺序换一下胜负可能就反过来。冗长偏好裁判模型倾向于给更长的回答打高分哪怕内容啰嗦。自我偏袒如果裁判模型本身也是生成模型它往往对自己生成的风格和内容更友好。这三个坑放在一起意味着你不能拿裸的LLM直接当裁判然后用它的分数当作唯一标准。可行的做法我列一下固定Rubric给裁判模型一个打分表明确从“事实准确性、工具调用合理性、回复简洁度、最终结果可执行性”几个维度打分每个维度给锚点描述而不是让它自由发挥。多裁判投票用两到三个不同厂商或不同规模的模型分别评分取中位数或做多数投票。单一裁判的偏见在多裁判下会被稀释。抽样人工复核每批自动评测里抽5%-10%人工看一眼。不是为了推翻机器分数而是持续校准Rubric的语义。模型对“简洁”的理解和人类不完全一样这个偏差只能靠人肉对齐。LLM as Judge是当前Agent评测成本最低的方案但它适合做“筛选”不适合做“定论”。筛选出明显好坏的结果没问题临界样本必须人工复核。这跟代码Review是一个道理自动检查工具负责拦住低级错误但最终上线前得有人拍板。2. Agent框架与工具链今天问得最多的一组问题热词里关于框架的讨论非常密集最集中的几个点是Harness和Agent到底什么关系、ADK在JVM上怎么跑起来、Spring AI Agent怎么用、Codex命令行Agent适合谁、Hermes Agent在Obsidian里怎么搭。2.1 Harness 和 Agent 到底有什么区别“Harness和Agent区别”这个热词能上榜单说明很多人和我当初一样被这两个术语绕晕了。先说我的结论Agent是“会思考的循环”Harness是“套在Agent外面的运行与测试装置”。两者不在一个层级。Agent的核心是一个大模型加工具集再加一个循环模型根据用户请求决定调用哪个工具、观察工具返回结果、再决定下一步动作直到认为任务完成。这个循环本身可以独立存在你可以写一个几十行的Python脚本实现它。Harness则更像是一个“舞台”。它负责管理工具注册、模型调用配置、上下文窗口、日志追踪、评测指标采集、并发调度。同一个Agent换一个Harness跑行为可能完全一样但可观测性、稳定性、并发能力完全不同。用生活类比来说Agent是演员Harness是剧组。演员负责演剧组负责灯光、场记、盒饭、意外处理。你只请演员来演他也能演但一旦出了错场、忘词、设备故障没有剧组兜底就乱了。实际选型时我的建议是如果你只是做玩具项目或验证想法不需要Harness直接写循环就行。如果你要对接多个模型供应商、要记录完整trace、要做自动化评测、要处理并发那就必须上Harness否则后期维护会非常痛苦。注意区分“Agent框架”和“Agent Harness”。LangChain这类偏编排框架提供了很多Agent组件而LangSmith、LangFuse这类偏Harness重点是观测和评测。两者不冲突但别指望框架自带完整的评测能力。2.2 三个值得试的上手路径ADK、Spring AI Agent、Codex今天热词里出现“adk.dev 的 Kotlin 快速上手在 JVM 上跑通一个 Agent”说明JVM生态的开发者也在找Agent入口。Google的Agent Development KitADK同时支持Python和Java/Kotlin如果你日常写Kotlin或Java那这套工具的体验会比较自然。JVM上跑通一个Agent的路径并不复杂大致三步用Gradle或Maven把ADK依赖加进项目网上有很多官方示例模板可以直接克隆。定义一个Agent给它起名字、指定模型、写一句系统指令再注册一个或多个工具方法。工具方法就是一个普通函数比如查天气、算订单金额只要能被框架识别成tool。启动REPL交互模式或者直接通过API调用输入一句自然语言Agent会自动决定调用哪个工具然后把结果组织成回复返回。整个流程跑通大概就是一杯咖啡的时间。背后的机制是框架把你的工具函数转成LLM能识别的JSON Schema模型在对话过程中看到工具定义后决定是否调用、传什么参数、怎么处理返回值。Web后端的主流选择则是Spring AI Agent。如果你已经在用Spring Boot加一套Agent能力不需要引入太多额外依赖核心思路是把LLM客户端封装成一个Bean通过工具方法注解实现Tool Calling再配合Prompt Template做用户输入到模型输入的转换。Spring AI最强的点是它在Java生态里与现有事务、数据库、监控体系整合非常顺。我自己试下来的感觉是项目里已经有Spring Boot体系时用Spring AI做Agent会比自研一套调用链省一半时间。再就是热词里那个“Welcome to Codex, OpenAIs command-line coding agent”。Codex是OpenAI推出的命令行编码Agent通过ChatGPT账号登录后它能在本地仓库里完成读取代码、修改文件、执行命令、提交改动这一连串工作。和前面说的框架式Agent不同Codex走的是“Agent即终端助手”的路线适合处理代码库里的机械化改造任务比如批量重构、补测试、修编译错误。我的看法是Codex这类工具解决的是“个人开发者生产力”问题ADK/Spring AI解决的是“把Agent嵌进你的业务系统”问题诉求不同不用纠结二选一。你要是只有一台电脑一个仓库想快速体验Agent写代码的爽感和翻车现场装个Codex就够了。2.3 Hermes Agent在Obsidian里跑Agent的第三方工作台热词里有一个“Hermes Agent Obsidian”和“Hermes Agent 第三方工作台”好几个同学都在问这个。如果你关注Obsidian插件生态这个话题确实值得看一眼。Hermes Agent是一类把LLM Agent接入Obsidian笔记系统的第三方工作台核心是让Agent能直接读写你的笔记库。它的价值在于你的笔记不只是给人看的资料而是能被Agent当作“记忆”和“知识库”来调用的资源。我实际体验下来的安装过程大概是这样的先确认你的Obsidian版本支持外部插件然后把Hermes Agent的插件目录放进.obsidian/plugins/下重新加载Obsidian即可在社区插件列表里看到它。在插件设置里配置模型端点、API Key和默认模型。建议把上下文窗口设置得小一点因为笔记库内容很容易把上下文撑爆。配置Agent可访问的笔记范围和目录权限只开放它需要的文件夹不要给它全库访问权限。建一个专用笔记作为“操作台”在笔记里以对话或指令块的形式调用Agent让它对指定笔记做摘要、找关联、生成卡片。这里有一个容易踩的坑Agent在笔记库里搜索时会把大量不相关的笔记片段拼进上下文既浪费token又降低回答质量。我建议先让Agent用文件名和标签做一次粗筛再决定要不要读正文而不是上来就全文检索。另外笔记是个人数据库把Agent接进来等于把个人数据交给第三方模型处理。建议优先接本地模型或私有化部署的模型接口别把含敏感信息的笔记直接送到公网API。这不是保守这是基本的数据边界意识。3. 可靠性工程让Agent从“能跑”到“能扛事”热词里有一条特别醒目“面向LLM智能体的自主容错控制构建可靠AI系统的工程实践”。这几乎是每个Agent项目从Demo走向生产都会撞上的墙今天专门展开说。3.1 自主容错控制给Agent装一层“安全带”Agent在生产环境里最大的问题不是“不够聪明”而是“不可预期”。模型可能改口、工具可能超时、外部API可能返回脏数据任何一个环节出错整套流程就可能崩掉。所谓自主容错控制核心不是让Agent不犯错而是让它在犯错时能自愈、降级或者兜底。我的工程实践是把容错分成四个层级层级对应环节容错手段L1 网络层LLM API调用超时、自动重试、指数退避、多供应商切换L2 模型层模型输出输出Schema校验、JSON修复、兜底回复L3 Agent层工具调用结果工具异常捕获、结果合法性校验、任务重规划L4 业务层最终交付兜底方案、人工介入队列、状态记录这里贴一段我常用的简化版容错外壳逻辑不复杂但实测很稳def run_with_guard(agent, task): for attempt in range(3): try: result agent.run(task, timeout60) if validate_output(result): return result logger.warning(output invalid: %s, result) except TimeoutError: logger.warning(attempt %s timeout, attempt) except ToolExecutionError as e: # 让Agent感知到工具错误并改用备用方案 result agent.run( f上一步工具执行失败{e}请改用备用方案继续, timeout30 ) if validate_output(result): return result return fallback_reply(task)这个模式的关键点有两个一是要给Agent一个“感知错误并重新规划”的机会而不是出错就直接返回失败二是所有重试都必须有次数上限避免Agent陷入死循环无限烧token。我见过最惨的一次线上事故就是一个工具返回了异常格式Agent反复重试了40多次账单直接爆掉。另外一个容易忽略的点是“输出校验”。LLM返回的结果不一定符合你的预期结构比如你要JSON它却回了Markdown你要字段名order_id它却写了orderId。我现在的做法是给每个Agent的输出定义一个JSON Schema模型返回后先做校验不合格就带着校验错误信息让它重新生成最多给两次机会。这样能拦住大部分“看起来能用实则解析必挂”的输出。3.2 Agent怎么扛并发先找瓶颈别盲目加机器“AI Agent怎么扛并发”这个热词背后是一个常见的误解以为Agent扛不住并发是模型不够快其实瓶颈往往在别处。Agent一次请求的消耗路径比普通API长得多模型要思考、要调用工具、工具要等外部响应、模型还要继续思考。这意味着单次请求的耗时可能是几十秒QPS一旦上来线程池、连接池、token预算、外部API限流每个环节都会爆。我建议按这个顺序排查LLM网关是否做了连接复用每次新建连接握手开销巨大必须走HTTP连接池。上下文构建是否合理如果每次请求都把大量历史记录塞进上下文不仅慢还费钱。把记忆做成分层短期对话记忆、摘要记忆、长期知识库按需取用。工具调用是否可并行如果Agent一次决策要读三个数据源让三个工具调用并行执行而不是串行等待。这四个工具串行要15秒并行只要5秒。Agent会话是否有状态隔离并发场景下最怕一个用户的状态串到另一个用户。每一个请求必须绑定独立的会话上下文或Agent实例不能共享可变状态。削峰手段有没有用户量上来时先把请求放到消息队列用worker池消费给用户一个“任务已受理”的反馈而不是硬抗瞬时流量。再补充一个运维层面的建议给Agent的每一次运行加上trace和指标记录模型调用耗时、工具调用耗时、token消耗、重试次数。没有这些数据你根本不知道瓶颈在哪只能靠猜。我自己就是把“工具调用耗时”单独统计出来才发现有个慢SQL拖垮了整个Agent跟模型一点关系都没有。3.3 两个高频报错排查实录热词列表里有两个非常具体的报错原文都是生产环境高频出现的单独拿出来说。第一个报错llm request failed: provider rejected the request schema or tool payload.这个报错我最近遇到不止一次字面意思是模型供应商拒绝了你的请求觉得你的Schema或工具载荷不合法。排查路径我按概率排序工具定义JSON Schema有误最常见的是某个参数忘了标type或者required引用了不存在的字段。把组装好的tools直接打印出来用JSON校验工具过一遍。供应商对工具数量或复杂度的限制有些网关一次只允许传少量工具或者不支持特别复杂的嵌套对象。试着先传一个最简单的工具如果能跑再一个一个加回来定位是哪条定义触发了拒绝。字段格式不兼容比如部分供应商要求additionalProperties必须是false有些则不允许这个字段出现有些要求所有参数都必须写description漏了可能被拒。这类问题需要对照供应商API文档逐项核对。绕过框架直接测试把最终发给供应商的payload抓出来用curl直接post过去看是不是框架在做转发时改坏了请求结构。第二个报错agent execution terminated due to error.这个报错一般不是模型本身的问题而是Agent执行器内部遇到了未捕获的异常。最常见的原因有三个工具函数抛了异常没有catch住、工具返回了无法序列化的对象比如Python对象直接return给模型、上下文窗口溢出导致执行器崩溃。我的排查方法是先开trace看执行器是在哪一步终止的。如果是工具调用后崩的那就在工具函数外层包一个try-catch把异常转成一段可读文本返回给模型让模型知道这个工具没成功而不是让执行器直接抛出。如果是序列化问题检查工具返回值是不是纯JSON可序列化的数据类型。如果是上下文溢出就要做摘要压缩或者限制历史轮数。这个报错最容易引起连锁反应执行器一崩整个用户会话就断了用户可能就再也收不到结果。所以生产环境里一定要在执行器最外层加一个兜底catch返回“系统繁忙”之类的降级文案保证用户永远能看到一个响应哪怕是失败响应。4. 模型、精调与本地部署的实战记录今天热词里模型相关的内容也不少我挑三个最值得说的Spatial LLM是什么、安卓老机器怎么跑GGUF、用聊天记录精调模型有哪些门道。4.1 Spatial LLM给模型装上“空间脑”“Spatial LLM”今天就挂在热词榜上。这个概念听起来玄其实落地场景非常具体让大模型具备空间理解能力能处理坐标、方向、布局、尺度关系。传统的LLM对空间几乎无感。你跟它说“把杯子放在桌子的右上角离边缘5厘米”它只能理解语义但换算不了坐标。Spatial LLM类模型则是把空间表示坐标、边界框、深度信息融入了训练让模型可以直接输出位置参数或者理解3D场景描述。应用方向现在主要在三个地方机器人操作从自然语言指令直接生成机械臂的目标位姿。室内导航把“走到沙发右边”翻译成具体的路径规划目标。AR/空间计算理解真实场景中的物体布局辅助虚拟内容摆放。如果你做的是这几个方向的项目关注Spatial LLM会比通用LLM有更直接的收益。但目前这类模型普遍比较重部署成本高大多数还停留在研究或demo阶段适合提前跟进别急着上生产。4.2 安卓8上跑GGUF本地LLM部署的另一条路“安卓本地运行GGUF格式LLM软件支持安卓8”这个热词应该是某个用户在寻找老手机上跑本地模型的办法。这事我折腾过结论是可行但期望值要摆正。先说一下GGUF是什么。它是llama.cpp项目推出的一种模型量化格式把大模型压缩成普通手机CPU也能跑的形式。在安卓上跑GGUF本质上是把llama.cpp编译成安卓可执行文件再加载量化后的模型文件。针对Android 8API 26这类老系统我的建议方案有两个方案A装现成的GGUF推理APK社区里已经有一些开源的安卓模型运行器支持导入GGUF文件并在本地运行。老机器优先选轻量级APK注意看要求的系统版本是不是在Android 8之上。装上之后找一个1B到3B参数的Q4_K_M量化模型文件大小大概在1到2GB之间导入后就能对话。实测下来3B模型在Android 8的中端旧机上生成速度大约每秒几个token能用但别期待流畅。方案BTermux llama.cpp手动编译如果你愿意折腾Termux可以在Android上提供一个Linux环境然后从源码编译llama.cpp。大致命令如下pkg install git cmake git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease .. make -j4 ./llama-cli -m ~/path/to/model.gguf -p 你好这个方案的优点是灵活可以自己调参数缺点是要花上一个下午而且Android 8上编译可能会遇到工具链兼容问题。如果主要是想体验本地模型我建议直接选方案A。运行的时候有几个必调参数-c控制上下文长度老手机建议设1024或2048别设太大否则内存直接爆-t控制线程数别超过CPU核心数温度建议0.7左右。模型跑起来之后一定要关掉网络再试确认它真的不联网这样才能保证隐私。4.3 用聊天记录精调LLM少走弯路的注意事项“使用聊天记录模型精调LLM”这个热词指向的是一个正经需求把手里的真实对话数据转成训练集精调一个更贴合自己场景的模型。聊天记录确实是很好的训练素材但直接用原始聊天记录去训练效果会很差。我建议的流程是清洗数据去掉时间戳、已撤回消息、系统提示、广告、重复内容。最重要的是去掉所有个人身份信息手机号、微信号、地址、姓名全部打码或删除这是红线。构造对话格式把聊天记录转成标准的messages格式。系统提示词固定写角色设定和行为规范用户消息放真实提问助手消息放理想回复。如果聊天记录里有多轮保留完整上下文但要注意截断长度。补充负样本只拿真实对话训练模型会学会你的回答风格但不会知道你讨厌什么。要额外构造“不该这么答”的样本或者在系统提示里明确禁止行为。用LoRA或QLoRA精调不建议全参数微调。全参数微调成本高、容易灾难性遗忘LoRA只训练一小部分参数效果好得多还能在消费级显卡上跑。评估要留一手不要拿训练集里的对话来评估要把一部分数据单独留出来当测试集。另外用LLM as Judge跑一轮批量评分再人工抽看能发现很多意外问题。JSONL训练数据格式大概是这样的{messages:[{role:system,content:你是某电商客服助手回复要简洁专业。},{role:user,content:订单三天没发货怎么办},{role:assistant,content:请提供订单号我来帮您查询物流状态。}]}一个容易翻车的地方是聊天记录里经常会有“机器翻译味”的回答比如客服话术里充斥着“很高兴为您服务”“感谢您的理解”。这些模板词会被模型学过去导致精调后的模型回复很僵硬。清洗时建议把这类套话统一替换成自然的口语表达或者直接删掉。5. 新词观察与问答速记日报的最后一部分留给今天的热词新面孔和几个短平快的问答。做日报时间长了你会发现很多热词其实信息密度很低但偶尔也会有几个词提前暴露下一个趋势。5.1 今天冒出来的几个新词“Agent Anywhere”这个词目前看到的信息还没有收敛到一个明确的单一产品上更像是“随处运行Agent”这类思路的代号。值得关注的方向是Agent不再局限于对话框里而是可以被调用到任意业务流程节点比如浏览器里、IDE里、IM机器人里。如果这个趋势成立那Agent框架的抽象层会越来越厚因为要适配的环境越来越多。“Pi Agent”今天也上了热词但信息比较散我没有确认到能直接推荐的项目。如果你正在查这个词我的建议是先确认你说的是哪个“pi”是某个个人智能体项目还是数学常数相关的工具链或者是某个仓库的缩写。方向不同完全不是一码事。我自己的处理方式是先把这类未证实的词放进观察列表等有更明确信息再下结论。“Agent Skill”则值得多说一句。这个概念和插件类似但思路更偏“给Agent一套专家级的标准操作流程”。一份Skill通常包含说明文档、示例、脚本或模板告诉Agent在什么场景下按什么步骤做事。今天热词里有一篇“Claude Agent Skills: A First Principles Deep Dive”我建议对Agent能力扩展感兴趣的读者找来看。它解释了为什么把技能外置而不是写死在模型里因为模型能记住的“操作手册”极其有限而技能包可以把操作手册放在模型需要的时候再去读取。这跟人类用SOP手册是一个道理没人能把所有流程背在脑子里但需要时会去翻手册。5.2 问答速记LLM单元测试、Agent画图、还有几句实在话热词里有“基于LLM的单元测试”我用一句话概括我的实践LLM适合做“测试生成器”和“测试评价器”不适合直接断言结果对不对。生成器负责读源码、看注释、生成测试用例评价器负责看生成出的用例是否覆盖了主要分支、断言是否有意义。但最终测试能不能通过、覆盖率有没有达标仍然要跑在真实的测试框架里。LLM生成的断言很容易出现“幻觉断言”——看起来在断言实际上什么都没检查。“Agent画图”这个热词也高频我简短说一下实现路径把绘图能力封装成一个工具这个工具内部调用绘图模型API接收Agent传来的风格、尺寸、主体描述参数返回图片URL。难点在于迭代闭环Agent自己是“看不见”生成出来的图的所以它很难判断图好不好。常规做法是再接一个图片理解模型或人类反馈把“这张图构图歪了”这个信息转化成文字返回给Agent再做第二轮出图。最后关于“支持…LLM”那类搜索词今天有几条涉及内容合规问题本日报不展开讨论也不做推荐。我的原则很简单分享技术可以但触碰安全底线和公序良俗的方向一概不碰这一点没什么可商量的。类似的合规边界在做Agent内容生成类功能时尤其要注意尽量在系统层就做好内容过滤别把问题留给模型随机发挥。6. 日报之外的闲谈今天日报编到这儿按惯例说点题外话。我自己的筛选标准一直很简单能落地的优先能引发讨论的次之纯标题党一概不收录。像AgentPoison这种论文虽然离生产环境还很远但它提醒我们一件非常现实的事当Agent开始大规模读记忆、读知识库数据源的信任边界就必须提上日程。以前做API只需要防输入注入现在做Agent还得防“记忆投毒”安全模型整个都不一样了。最后再分享一个小习惯算是我做Agent工程以来的切身教训给Agent的所有外部输入包括检索回来的文本、工具返回的数据、甚至是上一轮的对话历史都过一遍“这真的是当前任务该信的内容吗”的轻量校验。不用很复杂一个几行字的判断就能拦住很多事故。我做AgentPoison相关的防御实验时也发现很多被污染的片段第一眼看上去都极其合理但一旦追问“这个信息是谁写的、是否经过验证”就会露出破绽。今天的日报就到这里。明天同一时间继续把值得看的东西按这个标准筛一遍有用的拿来说没用的直接略过。