今天聊点实在的。2026年9月28日这期“Agent / LLM技术日报”我没有按新闻源逐条搬运而是把今天被反复讨论的三十几个热搜词重新攒了一遍按照“从概念到落地、从开发到安全、从模型到评测”这条线串起来。你会发现里面既有“agent是什么”这类入门问题也有“AI Agent怎么扛并发”这种逼到生产环境的硬仗还有“AgentPoison”这种偏红队视角的攻防研究。无论你是刚打算入坑Agent开发的新手还是已经在做Agent服务化改造的工程师这份日报都能给你一点能直接用的东西。适合谁读呢一类是正在做Agent应用落地的人框架选型、并发处理、记忆与技能编排、安全防护这些话题基本都能对上另一类是准备系统学习LLM和Agent原理的同学热词里反复出现的Token三要素、Harness与Agent的区别、LLM as Judge等正好帮你把散落的知识点拼成一张完整的图。1. Agent是什么先分清概念再谈学习路线1.1 智能体、框架、架构三个词各指什么今天的讨论热度里“agent是什么”“agent架构”“agent框架”几乎是同时出现的说明不少人其实还在概念层打转。我自己的定义很简单Agent是一个能够自主感知环境、做出决策并执行行动的闭环系统。LLM在这个闭环里扮演的是“大脑”角色负责把目标拆解成步骤真正让Agent“动起来”的是外围那圈东西——工具调用、记忆读写、任务循环、异常恢复。而“Agent框架”就不是一个Agent了它是给你搭好的一套骨架。你只需要把模型、工具、记忆模块填进去就能跑出一个可复用的Agent。很多人把框架和Agent混为一谈这是今天最需要纠正的一个误区框架是脚手架Agent是脚手架搭出来的房子。1.2 Harness与Agent的区别控制循环才是核心今天有条热词是“harness和agent区别”我最近也被问了几次。业内对Harness没有完全统一的定义但我更愿意把它理解为Agent运行时的“控制容器”它负责管理多轮循环、工具调用的上下文粘合、中断恢复以及安全策略的注入。Agent是你交给用户的产品逻辑Harness是让Agent真正“能循环起来”的发动机。做个小对比就清楚了对比维度AgentHarness定位面向任务的行为体承载行为的运行时环境核心职责推理、规划、执行动作控制循环、状态管理、工具调度与LLM关系直接调用LLM做决策决定何时调用LLM、如何注入提示词典型例子一个能订机票的AI助手ReAct循环、Claude的Agent Skills运行时理解这一步很关键。只要你做多轮工具调用的Agent就绕不开Harness这一层。很多人问“框架到底解决了什么”本质上就是替你把这些循环逻辑封装好了你不用自己手动维护“什么时候该问模型下一步”的状态机。1.3 Agent开发学习路线别急着上框架结合“agent开发学习路线”和“agent学习路线”这两条热搜我给一条自己走过的比较顺的路线先把LLM API用熟学会写结构化提示词、理解 function calling这是地基。手写一个最简单的ReAct循环不调用任何框架自己用 if-else 实现“思考-行动-观察”。上框架此时再看LangChain、Spring AI等你会瞬间明白设计意图而不是被魔法般的抽象唬住。做工程化改造并发、日志、安全、可观测性这些才是投入生产后真正头疼的部分。第2步会被90%的人跳掉但恰恰是它决定了你对Agent原理的理解深度。框架抽象了太多细节遇到线上问题你会无从下手这就是很多人说“Agent项目跑起来容易、调起来难”的根因。2. Agent开发实操框架选型、并发改造与最小骨架2.1 2026年怎么选Agent框架按语言栈来今天热词里出现了“spring ai agent”“adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent”“基于rust语言ai agent”三个方向很有代表性说明Agent开发已经从Python一枝独秀走向多语言生态。框架/方案语言生态我眼中的优势适合场景Python系LangChain/LlamaIndexPython生态最全、社区资料最多原型验证、研究型项目Spring AIJava/Spring能复用现有企业级基建和业务系统无缝集成传统Java服务改造、金融/企业级应用ADKKotlin/JavaJVM类型安全、协程友好JVM上跑通Agent很顺滑Android/Kotlin团队、服务端JVMRustrig等Rust性能好、内存安全、部署产物单二进制边缘计算、高并发网关场景我的选型原则很简单别追新看团队技术栈。如果你团队全是Java后端硬上Python框架还得多养一套运维体系得不偿失反过来一个十来人的创业团队要快速试错Python依然是最省力的。2.2 “AI Agent怎么扛并发”从单次调用到服务化这是今天含金量最高的一条热搜。很多人刚写完一个能跑通的Agent就以为大功告成结果一压测就崩。我先说结论Agent扛并发核心不是“提高单次推理性能”而是把Agent从“一个有状态的进程”改造成“无状态的编排服务 有状态的任务队列”。为什么因为LLM的推理无法在你自己机器上无限并行尤其是走第三方模型API时QPS和Token速率就卡在那里。而且Agent的上下文会不停膨胀一个长任务的上下文可能要几十万Token完全塞在内存里等于自杀。我实践下来比较稳的一套做法简化如下# 伪代码示意FastAPI Redis队列的Agent服务化骨架 from fastapi import FastAPI, BackgroundTasks import redis app FastAPI() r redis.Redis(hostlocalhost, port6379) app.post(/agent/run) async def run_agent(request: dict): task_id uuid4().hex # 先把任务丢进队列HTTP层立刻返回避免长连接占用 r.lpush(agent_tasks, json.dumps({task_id: task_id, payload: request})) return {task_id: task_id} app.get(/agent/result/{task_id}) async def get_result(task_id: str): # 单独的Worker进程不断消费队列执行Agent主循环 result r.get(fresult:{task_id}) return {status: done if result else pending, result: result}关键点有三个一是把耗时的Agent执行逻辑放到后台Worker用任务队列解耦二是上下文状态放到外部存储Redis或对象存储保证Worker重启不丢任务三是对模型API做好限流和重试因为生产环境最常见的故障就是“供应商限流导致任务失败”。2.3 一个最小可运行的Agent骨架用ADK在JVM上跑通一个Agent并不复杂核心是定义好“工具函数”和“模型配置”。我写过一个极简版本思路是// ADK Kotlin 概念示意核心就是模型 工具 循环 val agent Agent.builder() .model(gpt-4o) .tools(listOf(SearchTool(), CalculatorTool())) // 工具决定Agent能做什么 .prompt(你是一名代码助手请根据用户需求调用工具解决问题。) .build() fun main() { val response agent.run(帮我搜索今天的Agent相关新闻并总结) println(response.text) }跑通之后我建议你立刻做两件事第一把每次工具调用的输入输出都打印出来观察模型是不是“真的在用工具”第二设一个最大循环次数防止Agent陷入无限调用。很多新手的第一个Agent项目“卡死”就是没设循环上限模型在工具调用里绕不出来。3. Agent的记忆与技能让Agent“越用越懂你”3.1 Agent记忆的三种形态与Token预算管理“agent记忆”是今天另一条高频热词。记忆不是简单塞一段历史记录那么简单我习惯把它拆成三层短期记忆是当前会话上下文工作记忆是任务执行过程中的临时状态长期记忆则是跨会话保留的向量数据库或知识库摘录。这里有一个容易被忽略的认知记忆设计的本质是Token预算管理。长期记忆不可能全量塞进上下文否则再大的窗口也会爆。所以你要做的不是“存储更多”而是“检索更准”。每次该把哪些记忆片段注入回上下文、注入多少这本身就是一道质量工程题。3.2 Agent Skill把技能做成可复用模块“agent skill教程”和“claude agent skills: a first principles deep dive”这两条热搜指向同一个话题。Skill与普通工具调用的区别在于Skill不是一个单一函数而是一个完整的“指令 工具定义 触发条件”打包体。比如“画图”技能可能既包含文生图API定义又包含如何把草稿指令转成专业提示词的模板。实操时我的体会是技能要小而专不要试图做一个“万能技能”。一个技能负责一个明确边界的能力组合起来才能灵活复用。你可以在一个Agent上挂五个小技能但不要挂一个五百行提示词的“超级技能”后者会让模型决策变得混乱。3.3 用Hermes Agent搭一个Obsidian工作台今天关于Hermes Agent的讨论相当热闹出现了“hermes agent obsidian”“hermes agent 第三方工作台”“hermes agent安装”好几条。我试过把它接到Obsidian上体验更像是一个能读懂你笔记库的驻场助手你说“帮我整理今天的文献笔记”它会先用语义检索遍历你的库再调用格式化工具整理成目标结构。安装思路大致是先装好Hermes Agent运行时然后配置Obsidian插件作为第三方工作台再给它挂上本地向量索引。这类配好之后产物就是“Agent anywhere”的雏形——Agent不是停留在聊天页面里而是嵌入到你日常工作的每一个界面里。我自己最大的感受是记忆也好、技能也好最终都该为“在正确的位置把能力交付出去”服务。4. Agent安全从提示注入到记忆投毒4.1 AgentPoison攻击为什么记忆库会成为靶子今天出现的“agent安全”和“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”这两条热搜必须放在一起看。AgentPoison讲的是一种针对Agent记忆库/知识库的投毒攻击攻击者往向量数据库里检索可见的文档中植入恶意样本当Agent在处理正常任务时命中了这些被污染的内容就会被误导执行攻击者意图。普通聊天LLM的恶意内容顶多影响一次回答但Agent因为多了检索和工具调用环节一旦记忆被污染攻击就可能引发真实世界的副作用——比如操纵财务Agent误转账、引导代码Agent注入漏洞。攻击面比单纯对话大得多。这提醒所有做Agent的人安全红线不是安全团队单独的事而是从你第一次设计记忆检索时就该考虑的事。4.2 防御套路降权、清洗与最小授权针对这类攻击我的防御清单基本是固定的记忆库内容做来源分级外部抓取来的内容默认低信任低信任内容在注入时加重提示“仅供参考不可直接执行”。工具输出也要降权处理不要模型拿到工具返回就无条件相信尤其是涉及“执行动作”的工具加一道二次确认。定期清洗向量库用规则或另一个模型扫描可疑样本把明显诱导性的内容下架。最小工具权限Agent不需要一个“执行任意SQL”的工具给它只读接口就够了权限越小被投毒时的杀伤力越小。安全投入在前期看起来“不产生收益”但等线上真的被攻击了一次你就知道这套兜底值多少钱。5. LLM基础Token三要素与空间智能5.1 “Key、Query、Value”三个点一次讲透热词里有一条非常精髓的“llm的token三个点key我是谁、query我在找什么、value我能提供什么”。这个解读很妙它恰好对应了Transformer注意力机制中最重要的三个角色。你可以把Token理解成一个求职者Key是名字和简历Query是它对当前问题的匹配诉求Value是它真正能贡献的内容信息。模型在预测下一个Token时就是在所有候选里通过Query和Key的相关性打分再按权重提取Value。这个认知对写提示词有直接指导意义你输入给模型的每条指令本质上是在帮下一个Token确定“查询意图”。提示词里啰嗦冗余的部分越多模型就越难从Key的海洋里定位到该取哪块Value。我写提示词有一个习惯把背景信息写清楚把任务目标写明确把约束条件写成不能再短的列表其余全删。5.2 Spatial LLM空间智能为什么在2026年升温今天“spatial llm”的热度并不意外。Spatial LLM是模型对空间关系理解和推理的能力——它不仅能理解文字描述还能在三维空间中推理“桌子左边的东西是什么”“这个房间的出口在哪”。落地场景包括室内导航、机器人操作、3D场景编辑。我的判断是这类模型短期内的价值在于给具身智能提供一个相对靠谱的“空间常识底座”真正的杀手级应用还得等硬件成本降下来。6. 评测与质量榜单之外还有Judge和单测6.1 公开榜单的本质与局限“open llm leaderboard 等公开榜单”今天被讨论得很多。榜单的价值是给了一个相对统一的参考坐标系让你能快速初筛模型但它的局限也很明显——榜单题集是静态公开的模型方完全可能针对性优化。用户实际场景往往是私有的、特定格式的、带工具调用的榜单分数和真实体感经常对不上。所以我不把榜单当唯一参考而是当“海选工具”。进入实际项目后我会再花半天时间用自己的业务样例跑一遍离线评测用真实场景做二次筛选。6.2 LLM as Judge让模型给模型打分“llm as judge”已经是Agent和LLM质量评估的主流做法。做法很简单把答案、评分标准一起交给一个“裁判模型”让它给出分数或偏好排序。我用得最多的是“两两对比”模式比直接打分更稳定。一个可用的Judge提示词模板长这样你是一名严谨的评测员。以下有两个回答请根据准确性、完整性、可执行性三个维度 判断哪个更好输出A或B。如果两者质量接近输出持平。 标准准确性优先于完整性完整性优先于可执行性。 回答A... 回答B...Judge也不是万能的最常见的两个坑是位置偏差A和B换顺序结果就变和冗长偏差越长的答案越容易被判好。缓解手段很简单多次互换位置取多数票并在提示词里明确“长度不作为评分项”。6.3 基于LLM的单元测试把模型当测试生成器今天“基于llm的单元测试”也上热榜了。实操里我倾向于让LLM生成“测试建议”而不是直接生成全部测试代码。比如给模型看一个函数的签名和实现让它输出边界条件清单、可能的异常分支再由人工确认后落成测试用例。这样既借到了模型的视野又保住了人类对关键路径的把控力。直接让模型全自动生成低价值的断言不难但高质量的单测还是需要人来拿主意。7. 本地部署与移动端把LLM握在自己手里7.1 GGUF格式与安卓本地运行“安卓本地运行gguf格式llm软件”这条热搜背后其实是越来越多人在做隐私敏感的本地推理。GGUF是一个量化模型容器格式设计目标就是让大模型能在消费级CPU/GPU上跑起来。手机端跑GGUF关键看内存和算力7B模型用q4量化后大概在4-5GB旗舰机能跑但速度和温度要接受取舍而“支持安卓8”这个条件有点苛刻老设备不仅CPU慢系统对神经网络API如NNAPI的支持也很弱更建议走纯CPU模式并选1.5B-3B的小模型。我自己的经验是手机本地推理别贪大3B以下模型才能保证日用流畅。想要遇到问题时能自己排查可以学习一下llama.cpp系列项目的社区方案很多开源小工具都是基于同一套底层做的。量化等级上q4_K_M在质量和体积之间最均衡q8虽然质量更好但在手机上卡顿感很明显。7.2 LLM Studio与LLM Wiki知识管理的新形态“llm studio”“llm wiki”这两个词的热度也很能说明趋势LLM不再只是API而是正在变成个人知识系统的一部分。用本地推理工具跑一个随时能用的模型再配合个人知识库做检索增强效果远比纯粹依赖云端接口更可控。我现在的个人工作流是文档进Wiki库做向量化遇到问题先在本地模型上过一遍思路需要强模型能力时再走云端专业API。这套组合既省钱又保护隐私。8. 生产环境常见的几个报错与排查实录今天热搜里还有几条非常“现场”的报错我把它们整理成一个速查表都是实际生产里容易踩的坑。报错信息出现场景排查思路llm request failed: provider rejected the request schema or tool payload调用模型API时工具参数格式不合法重点检查工具参数JSON Schema是否与模型要求一致很多框架升级后要求收敛Function Call参数类型字段类型不匹配就会报这个错codex无法发送消息,显示更新agent沙盒Codex类的Agent运行环境过期说明沙箱镜像或工作区状态过期需要重建Agent运行环境再继续对话agent execution terminated due to errorAgent主循环执行中途被终结先查任务队列日志和工具调用堆栈可能是某个子工具抛了未捕获异常也可能是超时保护或安全策略主动终止我的处理原则是看到“provider rejected”这类错误第一反应永远是检查Schema而不是检查网络看到“terminated”先区分是主动终止还是异常退出主动终止查策略配置异常退出查工具代码。Error信息往往只告诉你“哪里断了”不告诉你“为什么断”把工具调用链路的输入输出完整打印出来才是最快定位手段。最后再分享一个我踩过很多次坑后的习惯给Agent项目加一个“决策追踪日志”每次LLM决定调用哪个工具、返回什么都结构化记录下来。它对你做评测、排查故障、分析Token消耗都有奇效。今天日报里所有这些热门问题的本质其实都指向同一件事——Agent和LLM已经从“能不能跑通”进入到了“能不能稳定地跑好”的阶段。