Agent 和 LLM 现在的技术社区每天都有海量讨论但真正能拿去落地的信息其实就那几十条。今天这份日报把我从社区热帖、开源仓库和一线交流里筛出来的内容全部过了一遍最后留下的都是和开发、选型、安全、踩坑直接相关的东西基本能回答“近期 Agent 圈到底在忙什么”这个问题。如果你正在做 Agent 开发、准备把大模型接进业务系统或者想系统入门 Agent 开发这份清单会很适合你。先说结论过去几个月“Agent 是什么”的讨论热度已经明显下去取而代之的是一批非常具体的工程问题比如 Agent 框架和编排层怎么选、Agent 记忆怎么设计、多个 Agent 怎么扛并发、检索到的知识会不会被投毒。这些话题不再停留在概念层说明这个领域已经从“我能跑通 Demo”进入“我要跑稳生产系统”的阶段。1. 当日趋势观察热词背后Agent 与 LLM 的工程化信号1.1 从热搜词看三个明显信号我翻了一圈当天关于 Agent 和 LLM 的热搜词第一反应是概念科普类的问题占比变少了“agent是什么”“llm是什么”这类基础问题已经不那么主流反倒是“agent框架”“agent架构”“agent开发学习路线”这一类带有明确行动指向的词牢牢占住了热度。这说明新一批开发者已经跨过“了解概念”的门槛进入“我该用什么工具、怎么搭、怎么排错”的阶段。第二个信号是安全相关的问题开始高频出现。“agent安全”“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”都进了热词池而且不是一个孤立现象。当越来越多 Agent 开始接外部知识库、接工具调用、接记忆存储投毒和越权就不再是论文里的概念而是真实业务里可能被利用的漏洞。这个问题我后面单独展开聊。第三个信号是“落地场景”变得非常具体。“agent画图”“agent skill”“基于langgraph的agent”“安卓本地运行gguf格式llm软件”“使用聊天记录模型精调llm”——这些词都是带着明确需求来的说明开发者在做的东西不再是聊天机器人而是带工具、带记忆、带特定技能的真实业务助手。1.2 热搜词里藏着的新方向Spatial LLM 与 LLM as Judge当天有两个词值得单独点一下。第一个是“spatial llm”空间大模型。传统 LLM 处理的是文本序列空间模型则要在理解语言之外建立对物理坐标、空间关系和物体方位的认知。它的应用场景很直接具身智能、机器人导航、AR 设备里的空间交互、室内无人配送。这个方向现在还偏早期但和“视觉语言模型”是两条不同的技术路线一个偏“看懂场景”一个偏“在场景中行动”。第二个是“llm as judge”用大模型来评估大模型。以前做效果评估主要靠人打分和规则匹配缺点是贵、慢、且对开放式回答无能为力。LLM as judge 的思路是让一个更强的模型当裁判对生成结果按给定维度打分。实操里要注意的坑是“裁判偏见”也就是评分模型偏好更长、更复杂、甚至带有特定措辞的答案。我通常的做法是给裁判模型提供正反参考样例同一个用例采样三次取中位数这样比裸跑一次稳定得多。1.3 我筛选日报内容的三条标准做这种技术日报最容易犯的错是把热度当价值。我给你透个底我每天从各个渠道捞到的话题少说几百条真正写进日报的通常只有二三十条。我的筛选标准很简单第一信息再热不能落地就不进库只有能转化成代码、命令、配置或排查步骤的内容才值得保留第二问题再小只要有人真踩过坑就值得记录因为小坑往往最费时间第三工具再好如果没有真实使用体验支撑我最多给个链接不会放进正文推荐。说到底日报不是资讯搬运而是把散落的话题提炼成“我今天能做什么”的行动指令。这也是为什么这份日报里你会看到很多“我建议你别这样做”的句子——那都是我拿时间换来的经验。2. Agent框架与架构选型模型之上的编排层是真正的骨架2.1 harness和agent的区别为什么这个区分最近被反复问“harness和agent区别”能上热搜我是有点意外的但仔细想想又在情理之中。很多新手第一次接触 Agent 项目时打开代码仓库发现到处都是 harness、runtime、pipeline 这类词立刻就被绕晕了。我举个例子你就明白了harness 是控制逻辑的壳它负责模型调用循环、工具注册、上下文维护、错误处理相当于一个舞台而 agent 是站在舞台上做决策的演员它会根据用户目标决定调用哪个工具、什么时候停止、什么时候需要追问用户。在 OpenAI 的 SDK 里Agent 对象负责定义指令、工具和记忆而 Runner 负责执行这个循环在其他一些框架里harness 可能叫 Runtime 或 Orchestrator。名字不一样但分工是一样的你写业务逻辑时主要在写 agent 的行为写稳定性和可靠性时主要在调 harness 的配置。把这个边界理清了很多“为什么我的 Agent 总在乱调用工具”的问题就解决了一半。2.2 ADK 在 JVM 上跑通一个 Agent比想象中简单“adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent”这个词条我非常有共鸣。JVM 生态在 Agent 开发里经常被忽略但企业后端大量用 Java 和 KotlinAgent 如果不能跑在 JVM 上接入成本立刻翻倍。我最近在一个熟悉的老项目里试了 ADK整体过程相当顺先建一个普通的 Kotlin 工程把依赖加进构建脚本然后定义一个 Tool 类暴露一个查询函数再把模型和工具装进 Agent 实例最后跑一个循环把用户输入交给 Agent 处理。跑通之后你会得到一个非常直观的感受Agent 不是一个神秘的东西它就是一个“循环”接收消息、判断工具调用、执行调用、把结果返回给模型、生成回复。这个循环的质量决定 Agent 的真实水平而框架只是在帮你把这个循环做得更健壮而已。我给的建议是在 JVM 上起步时不要一上来就纠结分布式、多 Agent、事件驱动那些高级特性先跑通单 Agent 的最小闭环后面再逐步加记忆和工具。2.3 Spring AI AgentJava 后端同学的最优切入点如果你所在的团队已经重度使用 Spring Boot那么“spring ai agent”几乎是你绕不开的选择。它的最大价值不是模型多强而是把 Agent 能力揉进了你已经熟悉的依赖注入体系里。你需要做的核心工作就三件事引入相关 starter 依赖、配置模型供应商的连接参数、把业务方法标记为可被 Agent 调用的工具。这种做法的好处是学习成本低坏处也和好处绑定——你很容易写出一个“看似集成完其实跑不通”的代码。最常见的问题有两个一是工具方法的入参和返回类型没有做严格约束模型传过来的参数经常会不符合预期二是把所有业务方法都注册成工具模型在决策时会“挑花了眼”。我建议你一开始只注册两到三个工具等调用链路稳定后再逐步扩展。2.4 选框架的取舍不要为了框架而框架ACE、LangChain、LlamaIndex、ADK、Spring AI Agent、基于 Rust 的轻量 Agent 框架市面上选择不少。但我想泼一盆冷水框架只是帮你省掉重复工作的工具不是业务本身。我在选型时只看三件事是否支持我需要的模型供应商、是否方便接入现有代码库、出现问题时的排查路径是否可控。对于个人项目我建议优先选社区活跃、文档完整的框架“agent框架与编排”这种词能火说明大家确实需要排错互助。对于企业正式项目Java 后端团队优先看 Spring AI AgentKotlin 团队优先看 ADKPython 团队可以继续用熟的那套生态。至于 Rust 那类轻量方案更适合做端侧部署和嵌入式场景性能出色但工具链还不够丰富别一上来就选。选框架最重要的是“你的团队能长期维护它”不是“它上过多少次热门榜”。3. Token、记忆与并发把LLM应用的地基压实3.1 Token 三要素Key、Query、Value就是“我是谁、我在找什么、我能给什么”“llm的token三个点key我是谁、query我在找什么、value我能提供什么”这条热词是我今天最想给所有人点个赞的表达。注意力机制里的 Key、Query、Value用这个口诀确实一下就讲透了。Query 源于当前正在处理的词或指令它在向整个上下文发出提问Key 是每个上下文单元贴的标签负责回答“我这个位置是什么”Value 才是真正的内容供给负责说“我能拿出什么信息”。老读者都知道我在讲 LLM 技术时很少让人背公式但这个类比值得记住。它解决的不仅是面试题更是实际调优问题——当你发现模型回答老是不对时先想一想是不是上下文里的 Key 不够清晰导致模型没有成功“找到”你要的东西当你发现模型输出太长时想一想是不是上下文里塞了太多无关 Value分散了注意力。调 Agent 很多时候调的就是这套信息检索和匹配逻辑。3.2 Agent 记忆短期、长期与业务结构化三层缺一不可“agent记忆”是近期被搜索次数飙升的主题。很多初级实现是把所有聊天记录都丢给模型靠上下文窗口硬扛。这在 Demo 阶段没问题一旦进入生产就会遇到两个瓶颈成本失控和上下文稀释。越早设计记忆后期越省钱。我的分层方案是三层。第一层是短期记忆就是当前会话的滚动上下文控制它不要无限膨胀快满时用摘要压缩。第二层是长期记忆把有价值的对话结果写入向量库需要时通过检索拿回来注意这里每一条写入内容都应该带上来源标记和写入时间。第三层是业务结构化记忆比如用户已选择的套餐、订单状态、审批进度这些不适合在自由文本里挖掘应该存成结构化的字段在工具调用时直接读取。三层记忆混在一起是 Agent 应用最常见的失控原因。3.3 AI Agent 怎么扛并发先做无状态再谈限流与队列“ai agent怎么扛并发”这问题我看到很多次了说明真的有不少项目在 Agent 上线后被打崩过。想清楚一件事就很好办Agent 实例本身应该是无状态的状态全部放外部。同一个用户的多轮会话靠会话 ID 从外部存储恢复上下文把 Agent 程序识别成可水平扩展的节点。状态丢在进程内存里两个实例一均衡用户的下一句话可能就接不上前文了。在此基础上并发治理和普通后端服务没有本质区别给模型供应商的接口做限流配置超时时间和重试策略长耗时的 Agent 任务丢进消息队列异步处理前端轮询拿结果。我通常会把模型调用的 QPS 估算提前写在设计文档里预留 2 到 3 倍余量。多 Agent 并发协作时还得加一条子任务结果要做幂等处理否则重试一次订单可能就重复创建了。4. Agent安全不该是“以后再说”记忆投毒与红队模拟4.1 AgentPoison 是什么不需要动模型权重只需要污染知识库“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”这个标题我第一次看到时就知道它是重要的研究方向。它揭示的攻击方式非常“阴”攻击者不需要碰你的模型文件只需要向 Agent 依赖的检索源里注入带有隐蔽扰动的文本当用户在未来某个时间点发出的查询触发了特定模式时被投毒的文档就会被检索优先命中Agent 随后就可能执行攻击者预设的行为。这带来的威胁是很多团队花大精力做了提示词防护却忽略了自己的知识库和记忆系统是暴露面。内部资料库一旦被混入恶意内容Agent 就成了“带毒的传话人”。别觉得这离你很遥远只要你的 Agent 接入了外部知识库来源、允许用户上传文档作为记忆、或者自动抓取网页内容就已经处在暴露面之内。4.2 缓解记忆投毒的实操清单我这里给一套能够直接落地的加固思路不一定需要重写架构第一知识来源做白名单管理内部知识库和外部抓取内容分桶存储检索时优先返回可信来源内容第二对写入记忆的内容做格式校验和内容扫描异常内容直接拒绝入库第三检索结果按来源可信度重排而不是完全交给相似度算法第四涉及资金、删除、隐私、发送消息这类高风险工具调用强制人工确认。最后一条建议可能听起来很“不智能”但在真实生产环境里这是最稳兜底。高阶玩法是把工具调用结果通过一个独立校验模型做二次审查相当于给 Agent 加一道“复核岗”。有读者问过这是不是会让超能降低我的回答很直接你宁可在安全性上慢半拍也不要拿线上事故去赌一个没有验证过的模型。4.3 内容安全与合规底线这不是附加题我在整理这份日报时有一类热词是直接跳过的比如涉及敏感内容支持的检索需求。这不仅是合规问题更是工程伦理问题。一个负责任的 Agent 开发者在设计系统时应该默认把内容审核能力留一个接口位无论你用的是哪家模型服务都得上游有限制、下游有兜底。工程上可以做的事包括对输入和输出两侧都做敏感词过滤工具返回值落库前做一次内容安全检测多模态场景下对图像生成结果做二次审核。很多开发团队觉得这是额外负担但等到出问题时代价往往比想象中大得多。安全做在前面才叫设计做在后面只能叫补救。5. 工程实战与报错急救从端侧模型到Agent工具箱5.1 安卓本地跑 GGUF 模型老设备的正确打开方式“安卓本地运行gguf格式llm软件支持安卓8”这条热词背后是一个很真实的场景有人想要把大模型跑在自己的安卓 8 老设备上不依赖云端。这个需求我完全理解本地跑模型的好处在于数据不出设备、不产生接口费用、没有网络延迟。但要跑得动需要端正预期。安卓 8 的设备内存普遍在 4GB 到 6GB 之间优先选参数量小、量化等级合适的模型7B 模型建议使用 4bit 量化文件大小约 4GB再往下 3B 甚至 1B 模型才是老设备的舒适区。推理时把上下文长度压到 2048 以内能显著降低显存占用。速度上别期待太高老机型跑 7B 模型通常每秒只有几个 token适合离线问答、文本分类这类短任务“边跑边聊”的流畅体验在云端更现实。5.2 Hermes Agent 与 Obsidian 工作台把笔记变成记忆源“hermes agent obsidian”“hermes agent 第三方工作台”这几个词连在一起看方向就很清晰了。Obsidian 在国内用户的心智里是本地笔记工具而 Hermes Agent 这类项目赋予了它新的角色——成为 Agent 的外部记忆源。你可以把 Obsidian 的某个文件夹当作知识库笔记写好后Agent 通过检索插件读取内容再结合模型能力回答问题或生成内容。这种“第三方工作台”的形态尤其适合个人知识管理场景。我自己的体验是笔记的价值不仅在于记录还在于能被重新找到。接上 Agent 后以前需要手动翻的笔记现在可以用自然语言问出来。但注意如果笔记里混入了过期信息或未经验证的内容Agent 也会一本正经地拿它做答案。所以给本地记忆库接检索时至少要加一个“来源文件路径”的回显让你能追踪答案出处。5.3 Claude Agent Skills从第一性原理理解“技能包”“claude agent skills: a first principles deep dive”这条内容我很看好关键是它把 skills 的本质讲清楚了。所谓 Agent Skill就是一段能复用的能力封装类似给 Agent 装了一个“插件”由描述文件说明什么场景下该使用它由提示词模板规范执行动作由脚本或工具接口完成具体操作再加上校验逻辑确认结果是否可用。第一性原理的角度最好理解Agent 的底层能力是语言理解和工具调用。真正限制 Agent 的不是模型不够强而是“模型不知道某个工具该怎么用、什么时候用、用错了怎么办”。Skill 就是解决这个信息不对称问题的说明书。很多团队把大量工具一股脑注册给 Agent效果反而差按 Skill 粒度组织每次只暴露当前任务相关的小块能力准确率和成本都能受益。5.4 当天热词里的报错急救速查表技术日报如果不带几个真实报错和排查方法总感觉少了灵魂。我把当天出现在热词里的三个典型报错整理成了速查表全部来自实际项目经历建议你收藏一份备用。报错关键字常见原因排查方向codex 无法发送消息显示更新 agent 沙盒本地沙盒进程异常、缓存冲突、本地 Agent 服务未正确启动先结束残留沙盒进程清理工作目录缓存重启本机 Agent 服务检查当前配置的服务地址是否指向正确环境LLM request failed: provider rejected the request schema or tool payload工具声明的 JSON Schema 与实际传入参数不匹配或模型不支持某些并行工具参数逐个检查工具函数的参数声明把声明与实际调用负载对齐将并行工具调用改为串行观察问题是否消失agent execution terminated due to error工具执行抛了未捕获异常或模型生成的工具调用参数超出范围查看完整堆栈定位是模型决策失败还是工具本身上执行失败给所有工具入口加 try/catch并返回结构化错误信息顺带说一句遇到这类报错不要第一时间怀疑模型供应商出故障先把问题的坐标系放在自己的代码里。八成以上这类问题都是工具定义和工程处理不到位导致的。5.5 Rust 写 Agent 与轻量离线部署“基于rust语言ai agent”这条热词说明关注轻量 Agent 的人越来越多。Rust 做 Agent 的价值我总结为三个词低资源、强类型、易分发。Agent 跑在 Rust 里没有 JVM 或 Python 运行时那么重编译产物可以静态打包往服务器、终端盒子和嵌入式设备上一放就能跑。这对于离线场景尤其重要比如工厂设备巡检、门禁语音助手能接受的能力可以做很轻的本地推理需要更强模型时则调用远端服务。但这不意味着所有项目都该用 Rust。Agent 的核心逻辑迭代非常快Python 和 TypeScript 在调用模型、数据分析、快速修改方面效率更高。我的建议很务实主力业务用熟人框架快速迭代当性能瓶颈和分发体积真正成为痛点时再把边缘模块用 Rust 重写收窄。5.6 Agent 画图与基于 LLM 的单元测试两个“看起来美”的场景“agent画图”这个需求很常见但落地时要注意模型的表达边界。Agent 真正参与的部分是理解需求、生成提示词、调整参数和验收结果画图本身交给专门的生成接口。你可以把它封装成一个 Skill用户描述想要的东西Agent 提取风格、主体、构图关键词改写好提示词后调用绘图服务最后读取返回的图片地址并用描述确认结果符合预期。这里最容易翻车的环节是参数抽取用户说“可爱点”是加词还是调强度每个团队都得在提示词模板里给出非常明确的规则。“基于llm的单元测试”是另一个热度很高的词但我必须提醒它没有听起来那么万能。LLM 确实能快速生成很多测试用例前提是目标代码接口清晰、输入输出类型稳定。如果代码本身就是一团乱麻LLM 生成的测试也只是在乱麻上叠新乱麻。我建议这样用先让 LLM 生成测试计划由人确认哪些分支值得测再让 LLM 去补具体的测试代码和测试数据最后人跑一遍覆盖率再合入。把 AI 放在提效的位置上而不是放在决策的位置上。6. Agent开发的学习路线与资源地图6.1 三个阶段从理解 Token 到玩转多 Agent 编排“agent开发学习路线”和“agent学习路线”这两条热词并列出现说明路线焦虑是普遍存在的。我给新手画一条我验证过的路线你就照着这个顺序走别一上来就啃多 Agent 框架阶段一夯实 LLM 基础。搞清楚 token 是什么、上下文窗口怎么计算、模型为什么会产生幻觉把注意力机制里的 Key、Query、Value 弄明白。不用背公式能讲清楚它们各自扮演的角色就够了。这一步大概花一到两周。阶段二做一个单 Agent。用你熟悉的语言选一个框架实现一个带一两个工具调用的助手。核心目标不是做得多炫而是完整走一遍“用户输入→模型决策→工具调用→结果返回→最终回复”的闭环加深对记忆、上下文、工具定义的理解。阶段三再去做编排。到了这个阶段再去学多 Agent 协作、事件驱动架构、任务队列、可观测性和安全防护。你会发现之前遇到的所有单点问题在这个阶段都会以系统化形式重新出现。前面基础越扎实这里越顺手。6.2 榜单、Wiki 与评测方法资源要会“用”而不是“收藏”“open llm leaderboard 等公开榜单”是很多人选模型的起点不过我要提醒公开榜单的分数只是在固定评测集上的成绩和你自己的业务场景往往存在偏差。正确用法是先用榜单缩小候选范围再在你自己准备的评测集上跑一轮看真实效果和成本指标。多花两小时做这轮私有评测能帮你省下后面几个月的迁移成本。“llm wiki”和“llm studio”这类工具我建议把它当字典和实验台来用。概念记不住就查 wiki拿不准模型行为就去 studio 里快速验证。另外一个评测思路是配合“llm as judge”做自动评估但注意给裁判模型设置清晰的评分标准必要时附上理想的参考答案否则裁判可能会被长答案带偏。6.3 一个可上手的项目参考清单基于当天热词里出现的技术点我整理了这份项目参考清单不一定非要原样照搬但可以作为你的练手选题参考项目方向技术栈建议适合练习的技术点个人知识工作台Hermes Agent Obsidian记忆分层、检索增强、来源追踪JVM 企业 AgentADK / Spring AI Agent工具注册、依赖注入、错误处理端侧离线助手Rust GGUF轻量部署、量化选型、性能优化安全加固实验任意框架 知识库内容投毒防御、输出校验、权限最小化照着这个清单做下来你基本能把 Agent 开发里最常用的几块技能覆盖一遍。做完任何一个项目都建议写一篇复盘把“为什么选这个方案”“踩了什么坑”“如果重来一次会怎么改”记录下来。做项目的真正收获从来不止是跑通代码而是这些决策过程。以上这些就是我这份日报里想讲的全部内容。我整理日报时有个习惯不把信息收进收藏夹就算结束而是从当天内容里挑出三个点立刻做一次实测哪怕只是跑通一个示例工程、修一个报错、调整一组参数都比保存三十篇文章更有用。Agent 和 LLM 这个领域发展太快但真正让你领先的从来不是比别人多知道几个名称而是比别人多解决几个实际问题。如果你今天只记住一件事我希望是这句话把每天看到的、讨论到的、收藏到的技术内容尽量转化成一次五到十分钟的动手验证你积累的就不再是消息列表而是解决问题的能力。