1. 今日核心焦点Agent 架构与框架之争今天社区里最热闹的话题绕不开一个词Agent。第二季度以来Agent 相关讨论已经从能不能做彻底转向怎么做好热搜词里密密麻麻全是架构、框架、编排、记忆、安全这类工程化关键词。作为一个每天泡在各种技术社区、GitHub 和论文堆里的人我把今天值得深入看的几个议题整理成这份日报尽量把热搜背后到底在讨论什么讲透。先说今天的主题背景。2026 年的 Agent 已经不是简单的调 API 套提示词了而是真正进入生产系统的多智能体协作、长任务执行、复杂工具调用的阶段。社区里讨论最多的是框架选型、Harness 和 Agent 的边界、Skill 的封装方式、Agent 怎么扛住真实的业务并发、记忆安全怎么兜底。这些话题看着分散实际是一条主线——Agent 从 demo 走向生产的必经之路。1.1 Harness 和 Agent 到底是什么关系harness 和 agent 区别能冲上热搜说明很多人被这两个词绕晕了。我经常用一个类比Agent 是大脑和手Harness 是身体和舞台。Agent 负责推理、决策、规划知道自己要干什么Harness 负责执行环境、工具注册、状态管理、循环控制决定 agent 能调哪些工具、调用结果怎么回灌、出错怎么重试。一句话Harness 管怎么跑Agent 管跑什么。举例说明。一个典型的 ReAct 循环里Agent 输出我需要查一下订单状态Harness 拿到这句输出后去匹配已注册的工具 schema把参数提取出来调用真实的订单查询接口再把结果拼回上下文给 Agent 继续推理。如果你没有 Harness这些流程就得自己在业务代码里手写工具发现、参数校验、错误分类、上下文裁剪、多轮循环计数。前 50 行可能还好写到并发控制、限流、日志追踪的时候就痛苦了。这也是为什么现在做 Agent 的人都强调要选一个现成的 Harness而不是从零造轮子。实际选型的时候我建议把Harness 和 Agent 是否解耦作为第一判断标准。好的框架两者分得很清Agent 策略层可以替换比如今天用 ReAct明天换 Plan-and-ExecuteHarness 执行层保持稳定。这带来的直接好处是换 Agent 策略不动工具注册代码加新工具不动 Agent 逻辑。今天讨论的 Claude Agent Skills、Spring AI、ADK 的社区方案本质上都是在解决如何把工具语义化地挂给 Agent这件事。1.2 框架选型ADK、Spring AI 与轻量路线的取舍今天热搜里出现了 adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent这条热度不低。ADK 是 Android 生态里做助手类 Agent 的官方套件Kotlin 版本的意义在于能让 JVM 老团队不用换语言就接入 Agent。我实测过它的流程核心是定义 Agent 类、注册 Tool、设置会话状态整体心智模型偏内置对话式适合做手机端助手、智能客服这类场景。如果你的后端已经是 Kotlin/Java 技术栈ADK 的学习成本确实最低。另一条是 spring ai agent。Java 后端的老牌玩家不可能没注意到它。Spring AI 的 Agent 抽象基本延续了 Spring 的约定优于配置风格和现有的 Spring Boot 服务集成非常顺。我见过不少团队把 Spring AI Agent 直接套在微服务架构里每个服务暴露一组工具再由一个编排 Agent 统一调度。它的好处是运维体系现成Actuator 监控、配置中心、链路追踪都能用坏处是模型侧的灵活性略差想跑非主流的推理框架时要多做一层适配。那轻量路线呢热搜里基于 rust 语言 ai agentai agent 搭建这两条代表的是另一拨人不想上重框架自己用几十行代码维护一个最小循环。Rust 做 Agent 的优势在并发安全和资源占用毕竟一个 Agent 跑起来要占上下文窗口、要开多个并发任务内存控制不住很容易爆。我的态度是团队小、场景单一可以先轻量但一旦涉及多工具、多会话、权限控制立刻切框架别在裸代码里硬扛复杂度。1.3 Claude Agent Skills 引发的技能封装思考claude agent skills: a first principles deep dive和agent skill 教程一起上榜不是偶然。Skills 这个概念今年被推得很火核心思想是把 Agent 的一项能力封装成技能包包含技能描述、工具清单、调用示例、校验规则。听起来就是结构化提示词工具配置但真正的难点在技能边界的定义。我做过的项目里有个反面教材把一个图表生成技能写得太宽导致 Agent 在生成柱状图时纠结半天要不要把饼图逻辑也塞进去最后输出质量反而不稳。后来我把技能按输入约束输出规范典型参数三个维度收紧效果立刻改善。所以 Skills 的实操要点就一句话技能描述要窄示例要具体校验要严格。你给 Agent 的技能越像一份清晰的岗位说明书它执行起来越不会跑偏。2. LLM 核心技术点Token 语义、裁判模型与评测榜单如果说框架是 Agent 的骨架那模型能力和 Token 理解就是血液。今天好几条热搜都指向一个基础但重要的概念值得展开说清楚。2.1 重新理解 Token 的三个投影Key、Query、Value热搜里有一条非常有意思llm 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么。这个概括相当精辟很多人第一次听会以为是在讲三元组实际上这是在用注意力机制的语言解释 token 在模型内部的角色。我用人话翻译一遍模型处理一句话时每个 token 都会生成三个投影向量。Query 代表我这个位置在找什么信息Key 代表我这个地方能提供什么语义标签Value 代表我被匹配上之后实际给出的内容。整个注意力机制就像一场圆桌会议每个参会者token都举着自己的 Key 牌子同时用 Query 扫描全场找对口的人找到之后大家把 Value 拿出来互相补充信息。这就是为什么上下文里的关键 token 会影响整个输出——它们提供的 Value 被大范围吸收了。理解这个对工程有什么实际帮助第一prompt 里关键信息要足够显眼让模型的 Query 能准确命中你可以用位置安排开头结尾和重复强调来辅助命中第二长文本处理时无关噪音 token 会干扰 Query 扫描所以精简上下文、做检索压缩不是洁癖是实打实提升输出质量的手段第三Agent 的记忆管理本质上就是在控制哪些 Key/Value 能进入圆桌会议。想通这三点很多 prompt 调优的玄学就变成了工程问题。2.2 LLM as Judge 的实用边界llm as judge也是今天的长青热搜。用大模型当裁判评估另一个大模型或者 Agent 的输出已经成为自动化评估的主流手段但它的坑比想象中多。我自己踩过的坑有三类一是位置偏差。同样的 A/B 两组回答A 放前面评分就偏高。后来我学会了把每个样本正反顺序各评一次再取平均能显著压掉这个偏差。二是措辞偏好。裁判模型容易被看起来更流畅、更长的回答带跑哪怕内容错误。对策是在评分 rubric 里明确要求事实正确性优先于表达流畅性并且给出反例。三是自我偏好。用自家的强模型评判自家弱模型结果天然不可信。所以我的建议是LLM as Judge 适合做批量初筛和回归不适合做最终裁决。流程上先让 Judge 跑一轮粗筛把明显高分的样本摘出来人工抽检复核争议样本再走人工仲裁。这套机器初筛人工复核的组合在真实项目里比纯人工快十倍比纯机器可靠得多。2.3 榜单背后的信号open llm leaderboard 等公开榜单能上热搜说明大家选模型时依旧离不开公开评测。但我想提醒一句榜单排名不等于业务实际表现。公开榜单测的是通用能力池子比如数学推理、知识问答、代码生成但你真实场景可能是售后工单分类或者合同条款抽取这两者相关性可能很低。我选模型的通常做法分四步第一步看榜单纯度掉那些基础能力差的模型第二步用自己业务里收集的 200~500 条真实输入跑一遍对比测试第三步重点看失败样本是理解错还是格式错这两类问题的解法完全不同第四步评估推理成本和延迟算清楚了才知道这个模型能不能上生产。公开榜单是起点不是终点这句话写下来和各位共勉。3. Agent 安全与稳定性投毒攻击与并发治理Agent 一旦接上真实业务安全和稳定性就成了绕不开的话题。今天热搜里的agent 安全和agentpoison: red-teaming llm agents via poisoning memory or knowledge ba这两条都属于必须严肃对待的内容。3.1 AgentPoison记忆投毒攻击AgentPoison 是今年学术圈讨论比较多的一种红队攻击思路。它的攻击逻辑很直观Agent 依赖记忆库或外部知识库做决策攻击者就往知识库里投放精心构造的恶意内容当 Agent 检索到这些内容时就会被引导做出错误决策。类比一下就像给一个顾问投毒——让他读到的资料全是假的他给出的建议自然越来越离谱。这个攻击最棘手的地方在于它不需要黑进你的 Agent 系统只要污染你的数据源就够。比如你的 Agent 用 RAG 从内部 wiki 检索答案攻击者如果能往 wiki 里塞一篇文章这篇文章对正常读者毫无攻击性但恰好能让 Agent 推理出错误结论。防御思路目前主要有三条知识库内容的来源校验和权限控制检索结果的置信度过滤低分片段不进上下文对 Agent 决策过程做敏感操作复核关键动作必须经过规则引擎二次确认。我的看法是第三点最务实——不要相信 Agent 的所有输出尤其涉及外部动作时加一层规则兜底永远不会错。3.2 AI Agent 怎么扛并发ai agent 怎么扛并发是今天最接地气的热搜之一。很多人从普通 API 开发转来做 Agent第一反应是把 agent 接口搞成异步不就行了实际远没那么简单。Agent 和普通接口的本质区别在于普通接口拿到请求执行一小段逻辑就返回Agent 拿到请求可能要跑好几轮模型推理工具调用的循环单次任务时长可能几十秒甚至几分钟。这种情况下你面对的并发模型完全变了。我总结下来的三件套是这样的任务队列 状态机 结果轮询。第一步请求进来先不进 Agent直接丢进队列Redis Stream 或 RabbitMQ 都行立刻返回一个任务 ID。第二步后台 worker 从队列拿任务驱动 Agent 执行每完成一轮就更新一次任务状态thinking / calling_tool / done / failed。第三步前端或调用方通过任务 ID 轮询状态完成后取结果。这套架构下并发瓶颈从模型推理转移到了worker 数量你可以用扩容 worker 的方式线性提升吞吐。我碰到过不少人问为什么不直接用长连接或 WebSocket 推送我的回答是轮询虽然不够优雅但实现最简单、最不容易出错生产环境优先求稳。还有一个细节Agent 的幂等性设计。工具调用可能超时重试如果工具本身不是幂等的比如创建订单发送短信重试就会产生重复副作用。设计 Agent 工具时一定要给每个任务带全局唯一 ID工具层做去重。这个问题不解决并发一上来就一定会出乱子。3.3 今日高频报错排查schema 校验与沙盒异常今天热搜里两条报错相关的内容非常典型llm request failed: provider rejected the request schema or tool payload和codex 无法发送消息显示更新 agent 沙盒。第一条报错信息里写得很明确provider 拒绝了你的请求原因是 schema 或工具负载有问题。这几乎是所有接 Tool Calling 的人都会踩的坑。常见原因有三类工具参数定义和实际传入不一致比如定义成 integer 传了字符串工具数量超过模型接口上限直接爆请求体某个工具描述里有模型不认的特殊字符。排错顺序我建议从简到繁先打印请求体看完整 payload再逐个检查工具 schema 的字段类型最后缩小工具集做二分定位。这招几乎每次都能快速解决问题。第二条是 Codex 沙盒相关的。沙盒环境更新后偶尔会出现客户端和远端环境不匹配的报错这类问题本质上属于环境和版本同步问题不是模型或业务代码的问题。我的经验是先确认客户端版本是不是最新再看沙盒的版本号是否需要重新构建/更新然后检查网络代理设置。都正常就清掉本地状态重新初始化。别一看到无法发送消息就慌着重写业务逻辑大概率环境问题冷静排查就行。4. 实操派本地跑模型与工程化落地今天的热搜里实操向的内容占了大半壁江山。我挑几条有代表性的展开讲讲这些都是可以直接照着做的干货。4.1 安卓本地跑 GGUF 模型安卓本地运行 gguf 格式 llm 软件支持安卓 8这条热搜背后是一整波本地推理需求。GGUF 是量化模型的通用格式把动辄几十 GB 的模型压到 4~8 GB才让手机本地跑模型成为可能。如果你是安卓 8 以上的设备实际可选的路线有好几条。比较主流的方案是用 llama.cpp或它的安卓打包应用跑 GGUF 文件配合 ARM NEON 加速中端机跑 7B 量化模型的速度大约在每秒 5~10 个 token做聊天、摘要这类交互完全够用。我的实际经验是选量化等级比选模型版更重要。Q4_K_M 是目前画质和体积最平衡的档位Q8 虽然更准但体积大一半速度也明显下降Q2 档压缩太狠输出质量会肉眼可见下降不推荐。内存方面也得规划好。7B 模型 Q4 量化后大概 4~5 GB 文件运行时还需要额外 2~3 GB 内存做上下文所以手机可用内存低于 6 GB 会比较紧张。上下文长度也建议先设小一点比如 2048实测跑起来会流畅很多不够再慢慢加。4.2 Rust 写 Agent性能与安全的两全方案基于 rust 语言 ai agent上榜代表了一批追求极致性能的开发者。Rust 写 Agent 的好处除了上一节说过的内存安全和并发模型还有一个常被忽略的优势无 GC 的确定性延迟。Agent 循环里的工具调用和状态更新如果频繁触发 GC在低延迟场景下就是灾难Rust 把这个问题从根上消除了。但我必须诚实地说Rust 做 Agent 的代价是开发效率。Agent 生态最成熟的工具链在 Python/TypeScript 里Rust 生态相对薄。我见过一个折中方案核心 Agent 循环用 Rust 写成一个高性能服务暴露 gRPC 接口上层业务和 prompt 管理用 Python 或 TypeScript两边通过接口通信。这样既保住了性能又没放弃生态灵活性。如果你现在问我要不要全 Rust 重写 Agent我的答案始终是一个字看场景。纯计算密集、工具调用极高频值得常规业务别和自己过不去。4.3 Hermes Agent Obsidian 的知识库联动hermes agent obsidianhermes agent 第三方工作台这两条连在一起看指的方向就很清楚了Agent 与知识库的深度绑定的需求正在变强。Obsidian 这类本地笔记工具成了很多人的个人知识库首选大家自然希望 Agent 能读取、检索甚至维护这些笔记。这类第三方工作台的实际用法我体验下来最实用的场景是把 Obsidian 库作为 Agent 的长期记忆和 RAG 数据源。你平时记下来的会议纪要、技术笔记、灵感碎片都自动变成 Agent 可检索的知识。和用向量数据库方案比Obsidian 的好处是文件本身可读、可维护Agent 写入的内容你能直接看到不会被锁在黑盒数据库里。不管装哪款工作台我都建议先想清楚三件事笔记的目录结构是否清晰、Agent 的读写权限怎么划分只读优先、检索范围怎么控制。权限问题处理不好Agent 误改笔记的破坏力可比输出一段错误代码严重多了。4.4 用 LLM 补单元测试的思路基于 llm 的单元测试这条热搜说明工程质量这个老话题开始拥抱新工具了。我的实际感受是LLM 最适合干的活不是从零写测试而是补测试你有一堆老代码没单测手写又被业务排期挤压这时候让 LLM 根据函数签名和上下文生成基础用例再由人审一遍边界条件效率能翻好几倍。实际操作我有一套固定流程。第一步把目标函数的签名、注释、依赖关系整合成一段精简 prompt第二步要求 LLM 输出 include 典型分支、边界值和异常输入的测试代码先不追求覆盖率只求能跑通的结构第三步把生成的测试丢进现有 CI 跑一遍红灯用例重点看是 LLM 写错还是功能真有问题第四步人工补几个 LLM 肯定想不到的场景比如并发、时间依赖。这套流程下来老模块的覆盖率从 20% 拉到 70% 通常只需一两天。但切记LLM 生成的断言往往偏弱喜欢用不为空不报错这类安全断言你需要人工强化核心业务断言不然测试就是纸糊的。5. 学习路线与生态观察日报的最后一部分聊点长期主义的议题。今天热搜里agent 开发学习路线agent 学习路线agent 项目这几条的讨论量很高但网上相关路线图鱼龙混杂我给一份自己验证过的精简版。5.1 一份 Agent 开发学习路线的建议我把学习路径分成四个阶段每个阶段对应明确的能力目标。第一阶段懂原理掌握 LLM 的推理机制、Token 概念、上下文窗口限制学会写结构化 prompt。这一步的目标是让模型稳定输出你想要的格式。第二阶段会调用把模型接进代码里掌握 Tool Calling 机制实现一个最小 ReAct 循环——让模型决定该调哪个工具然后你执行工具并把结果回灌。这是从聊天机器人跨向Agent的关键一步。第三阶段懂编排学习多工具注册、上下文管理、记忆机制、错误重试开始理解 Harness 的重要性。第四阶段做工程研究并发模型、沙盒隔离、安全防护、可观测性把 Agent 放进真实生产环境里接受检验。我自己见过最多人卡住的位置是第二阶段。原因往往不是代码难写而是**没理解模型输出只是建议执行权在你手里**这个原则。Agent 的核心逻辑是你写的循环不是模型决定的。想通这一点后面学编排和工程就顺了。5.2 今日值得关注的项目与工具最后收个尾列几个今天我在社区里看到、觉得值得跟进的项目方向方便大家顺着去挖。一个是 agent anywhere这类项目在做的是让 Agent 在多种入口和环境中无缝迁移比如同一个 Agent 逻辑既能跑在命令行、又能跑在 IDE 插件里另一个是 hermes agent 系列围绕个人知识库和工作台的联动越做越深适合知识管理党还有 pi agent 这种偏个人助理方向的项目核心在长期记忆和主动提醒。再加一个 agent ransack 相关的搜索增强方向解决的是 Agent 如何更高效地在大规模文档里找到需要的信息——这几乎是所有企业级 Agent 的刚需。今天的热搜词里还有一个有意思的观察agent 画图这类垂直能力需求也开始稳定出现。说明 Agent 的应用正在从通用助手向垂直技能深化每个细分场景都值得被认真做成一个 skill。做 Agent 生态的人看到这种信号应该会挺兴奋的——这意味着真正的应用层机会才刚刚开始。