尧图网站建设 
早上刷完知乎技术时间线今天2026-09-28的 Agent / LLM 讨论密度明显比前几天高出一截。OpenAI 的 Codex 命令行智能体、Hermes Agent 在 Obsidian 上的第三方工作台、LLM as Judge 的可靠性之争、AgentPoison 这类红队研究接连出现几乎每个话题背后都牵着一个一样的痛点智能体到底能不能从“能跑起来”跨到“值得信任”。这篇日报不打算面面俱到只挑今天值得展开的技术点拆开讲。适合正在做 agent 开发、准备把大模型接入生产流程的人也适合刚入门想找 agent 学习路线的新手——我会把工程细节和踩坑经验混在一起写尽量让不同基础的读者都能看懂。1. 今日选题解读Agent/LLM 生态在争什么1.1 热词拆解今天的讨论集中在哪几个方向把今天的热搜词丢进一个词频池里能明显看出四条主线。第一条是开发基建agent 框架、agent 架构、agent 框架与编排、agent 开发这些词成组出现说明大家还在纠结“我的智能体应该用什么姿势搭”。第二条是能力扩展Agent Skill、agent 记忆、多 agent、agent tool 成组出现意味着单纯会调用工具的 agent 已经不够看了社区开始追求可复用的技能包和长期记忆。第三条是生产化agent 安全、AgentPoison、LLM as Judge、自主容错控制这些关键词的热度说明很多人已经从“做个 Demo”转向“怎么让它在线上不出事”。第四条是开发者工具链OpenAI Codex、Hermes Agent、基于 Rust 的 AI Agent、安卓本地跑 GGUF 这类项目正在把 agent 能力塞进各种意想不到的环境里。这个结构其实反映了一个行业变化2026 年的 LLM 基础能力已经非常稳单纯的“谁家模型强”不再是讨论焦点。大家的注意力从模型本身转移到模型外面的那一圈——工具、记忆、评估、编排、安全以及“基于 LLM 的单元测试”“用聊天记录精调模型”这类把模型能力揉进工作流的具体玩法。说白了模型是发动机但决定一辆车好不好开的是底盘、悬挂和驾驶员决策逻辑。今天的所有热点基本都在围绕这个“车架子”打转。1.2 今日快速情报几条不展开但值得知道的消息整理日报时我有个习惯把今天出现但暂时不值得展开的消息单独列一组避免占用正文篇幅也给有兴趣的人留个索引。今天这组算是近期比较有意思的基于 LLM 的单元测试热度不低核心玩法是让模型从需求描述反推测试用例再拿真实代码补全断言。实际用下来效果不错但常产生过度断言需要人肉删减。LLM Studio 与 LLM Wiki前者是图形化的模型微调和评测工作台后者是一个把团队知识库跟模型检索绑定的协作项目。两者都偏“工具全家桶”对团队效率有帮助但对个人开发者来说学习成本偏高。Spatial LLM关键词指向空间理解能力比如让模型读取点云、地图栅格、室内布局描述。这会辐射到机器人导航和自动驾驶场景值得关注但短期不推荐所有 agent 开发者投入。Agent 画图多模态 agent 集成画图能力已不是新鲜事今天讨论集中在如何让画图 agent 接受“修改其中某个物体的位置”这类细粒度指令背后是区域编辑和结构化图像生成。Agent everywhere偏产品落地向讨论的是把 agent 做成嵌入到鼠标键盘、IM、笔记软件里的常驻能力核心争议点是常驻权限和数据隐私。我每天汇总时会刻意区分“新闻”和“信号”。新闻是出了一件事代表当天热度信号是这件事背后暗示的长期趋势值得花一周甚至一个月跟踪。上面这几条里基于 LLM 的单元测试和 Spatial LLM 更像是信号其余几条更像是新闻。判断标准只有一个它会不会改变你未来三个月做 agent 的方式。2. 框架、编排与 Agent Skill开发者的主战场2.1 Harness 和 Agent 到底有什么区别今天有个热词很有意思harness 和 agent 区别。很多刚开始做 agent 开发的朋友会把这两个词混在一起因为它们经常同时出现在框架文档里。我用食堂打饭来做比喻Agent 是那个打饭的学生harness 是食堂的动线设计包括取餐台的顺序、窗口怎么分配、餐具回收在哪。学生可以灵活决定先打菜还是先打饭但动线决定了整个流程能不能顺畅跑完。技术上拆开看harness 通常指负责承载 agent 运行循环的那层基础设施。它管的事包括维护上下文窗口、处理工具调用的往返、在 agent 输出格式错误时做恢复、把外部事件转换成 agent 能理解的消息、以及记录完整 trace。而 agent 本身更多指那个负责“下一步做什么”的决策单元通常是一个模型加提示词再加上它惯用的工具集。你可以完全手写一个 harness也可以直接用 LangGraph、AutoGen 这些编排框架来当 harness然后把自己的 prompt 和工具塞进去。真正写项目时大多数人纠结的“用框架还是不用框架”本质上就是“我要自己修多少 harness 的轮子”。我在实际项目里比较推荐的做法早期 Demo 直接手写一个 60 行的 run loop把模型调用、工具分发、结果回填串起来先确认业务逻辑走得通等系统复杂度上来了再把循环交给成熟的编排层。这样你既能理解 harness 每部分在干嘛又不至于一开始就被框架的抽象束缚住。拿 ReAct 循环举例最简版本无非就是“让模型给出下一步动作 → 执行工具 → 把结果追加到消息列表 → 再问模型”。这四步你能亲手写一遍再看任何 agent 框架的文档都会顺眼很多。2.2 Claude Agent Skills一种可复用的能力封装今天社区里“claude agent skills: a first principles deep dive”这篇帖子被反复引用跟“agent skill 教程”的热度是同步的。Agent Skill 这个概念并不是新发明但最近因为 Anthropic 在 Claude 里把它产品化重新引发了一波讨论。本质上看skill 就是把一组完成特定任务所需的指令、上下文、工具调用模板和相关资源打包成可以被 agent 直接加载的模块。它比单个 tool 更抽象tool 是一个可调用函数skill 是一整套“怎么用这些函数完成一件完整的事”的方法论。举一个今天被问很多的例子agent 将网页保存成 markdown 的 skill。如果只是做个 tool你可能会写一个函数输入 URL 输出 markdown很简单。但要做一个 skill你要考虑的是先抓取网页还是先看 robots正文提取时对哪些标签降权图片是保留链接还是下载本地链接要不要去重和归一化最后输出到哪个目录命名规则是什么。这一串决策放在 prompt 模板里再配上抓取和转换脚本打包成一个文件夹agent 随时可以调用这才是 tool 到 skill 的层级差异。如果你打算给自己的 agent 加 skill我给一个简单可复制的结构。文件夹里放一个 SKILL.md用 YAML 头部声明 name、description、参数 schema正文用固定模板写“什么时候用、怎么调用、输出规范、注意事项”脚本放在同目录下description 里写清楚入口命令。一个保存网页为 markdown 的 skill 头部大概长这样--- name: web_to_markdown description: 抓取单个网页正文并转换为干净的markdown文件适合做信息收集和笔记沉淀 params: url: string # 需要抓取的完整URL output_dir: string # 输出目录默认为当前笔记目录 download_images: boolean # 是否把图片下载到本地 ---实际测试时你会发现description 写得越具体agent 越不容易在错误场景里误用这个 skill。比如只说“保存网页”不够要写“适合正文型内容不适合需要登录的页面”模型在遇到不适合的场景时会主动询问或跳过。这是花十几分钟就能见效的调优动作别偷懒。2.3 今日工具动态OpenAI Codex 与 Hermes Agent今天工具链方面的最大动静是 OpenAI 的 Codex 从研究预览走向更开放的落地。社区里一句“welcome to codex, openAIs command-line coding agentsign in with chatgpt”被转得很广因为它释放了一个明确信号编码智能体正在成为 CLI 的第一公民。Codex 的工作模式是让你在终端里授权它访问仓库然后它自己完成读代码、改代码、跑测试、提交 PR 这一连串动作。相比之前在 IDE 里靠人点按钮CLI 版本更适合放进 CI 里跑也更容易嵌入到你现有的脚本工作流。比如你可以把它接到一个自动处理 issue 的队列里模型改完代码之后自动跑一遍单测接着提交分支由人来 review。另一条线是 Hermes Agent。今天热搜里 Hermes Agent 官网、hermes agent 安装、hermes agent 第三方工作台、hermes agent obsidian 扎堆出现说明这个项目正处在用户快速扩张的阶段。Hermes Agent 给我印象最深的是它对“工作台”的理解它不是只给你一个聊天输入框而是把任务列表、文件变更、工具输出、运行记录组织在一个侧边栏式的界面里有点像给 agent 装了一个驾驶舱。很多人问 Obsidian 里的第三方工作台怎么用其实思路很简单把 Obsidian 当成 markdown 的编辑器和知识库Hermes Agent 负责在后台执行任务再把结果写回笔记形成一个“输入想法-自动执行-沉淀笔记”的闭环。我实测下来觉得这类工具初期最实用的场景不是替你写代码而是帮你做信息整理。比如你丢给它十几个网页链接让它抓取正文、去重摘要、自动生成一篇带二级标题的 markdown 汇总笔记它通常能比你自己手动复制粘贴快得多。前提是你把 skill 或者指令模板写好并且给足输出目录的权限。别一上来就让它全自动操作你的 git 仓库先让它干点低风险的活建立信任感。3. 安全、评估与容错Agent 进入生产的三个坎3.1 AgentPoison记忆中毒攻击的威胁模型安全相关的热词里AgentPoison 今天讨论度不低。原因很简单它攻击的不是模型权重而是 agent 的记忆和知识库这让很多人第一次意识到 RAG 并不天然安全。AgentPoison 的核心思路是红队视角往 agent 会检索的记忆文档里投放经过特殊构造的文本让 agent 在读取这些“知识”时被引导执行攻击者想要的操作比如修改某个重要文件、跳过权限校验或者泄露存在上下文里的敏感信息。这和传统提示词注入的差别在于注入不再依赖用户当前这条消息而是藏在历史记忆或外部知识库里被称为“持久化注入”。工程上最让我担心的一点是很多 agent 框架默认信任所有检索回来的内容把向量数据库里的片段直接塞进上下文这就等于让攻击者拿到了一个长期后门。防御角度我建议至少做三件事给每条记忆记录来源和可信度标签对检索内容做离线的敏感指令检测比如发现内容里带有“忽略之前的指令”“执行系统命令”这类模式就降权关键操作一律要求二次确认不让 agent 直接执行由记忆内容推导出的高危动作。这三层听着基础但在今天的生态里已经能挡住绝大多数已知的投毒路径。3.2 LLM as Judge 与元评论残留问题LLM as Judge 现在几乎是做 agent 评测的标准姿势但今天知乎上有个讨论戳中了很多人的痛点用大模型给大模型打分时出现了“LLM 元评论残留”的问题。所谓元评论残留就是 judge 模型在产出评分时把自己的思考过程、系统提示语、甚至对被评测模型的偏见带进了最终评价文本里。比如你让 judge 给两个回答排序它却在输出里点评“这两个回答都只覆盖了浅层知识”。这句话如果被当作结论使用整个评测就失去意义了。我的经验是用 LLM 当裁判最关键的是限制它的输出空间。不要让它自由发挥写评语而是把评分维度拆成离散选项比如相关性、完整性、安全性各打 0-5 分并且要求它必须按 JSON 格式返回禁止输出 JSON 之外的任何解释。其次要做评测盲化被打分的模型输出不要附带模型名和 prompt 元数据否则 judge 容易被品牌效应带偏。最后建议定期抽样做人工复核把 judge 明显误判的样本收集起来写进 judge prompt 的 few-shot 例子里。这个迭代成本很低但能把评测准确率从“看个大概”拉到“可当回归基线”。3.3 构建可靠 Agent自主容错控制的工程实践“llm 智能体自主容错控制构建可靠 AI 系统的工程实践”这个热词背后其实是每个 agent 从原型走向生产都要面对的三座山模型会崩、工具会挂、编排会乱。自主容错不是说让 agent 自己重试几次就行而是要建立一整套异常处理链路。我常用的骨架调用任何外部工具之前先生成 planplan 里标注每步的前置条件和预期结果工具返回后先做 schema 校验字段缺失立刻终止这一步而不是继续往下跑遇到错误时把错误原文、模型输出、相关 trace 一起打包进回退指令让模型在少一轮试错成本的前提下修正最关键的是全链路日志每一条 tool call 都记录下来否则出问题时你根本没法复盘。一个典型的容错循环骨架async def run_agent_loop(initial_state): state initial_state for attempt in range(3): try: plan await model.plan(state) for step in plan.steps: result await call_tool(step) validated validate_schema(step.expected, result) if not validated.ok: raise ToolOutputError(step.name, validated.detail) state merge_state(state, result) return state except (ToolOutputError, ModelOutputError) as e: state[error_feedbacks].append( fattempt {attempt}: {str(e)}\nlast trace: {state[trace][-5:]} ) if attempt 2: return {status: failed, state: state} return {status: failed, state: state}循环外面还要加一层超时熔断。单次 agent run 超过 90 秒就发告警并转人工因为大多数真实任务里一个 agent 卡住带来的损失远大于它多跑几分钟可能带来的改善。灵活性是好东西但要给灵活性加上护栏。4. 学习路线与轻量落地新人怎么跟上节奏4.1 从 Agent 基础到多 Agent 的路线图今天热搜里同时出现了 agent 学习路线、agent 开发学习路线、agent 框架、llm 框架、agent 项目显然有一大批人正准备入坑。我按自己带过人的经验把路线压缩成五个阶段。第一阶段是念清楚协议搞明白 token、上下文窗口、function calling 这几个概念能自己用 provider 的 API 完成一次带工具调用的对话。第二阶段是手搓最小循环不依赖框架把“模型出提议-解析工具调用-执行-结果回填”写出来。第三阶段开始选编排层这时候再去看 LangGraph、AutoGen或者直接读成熟 agent 项目源码你会发现自己已经能读懂大部分设计取舍。第四阶段做记忆和评估给 agent 加短期会话缓存和长期向量记忆同时用真实的错误 case 建一个 eval 集。第五阶段再碰多 agent 和复杂技能编排因为协作复杂度和定位问题的成本都是指数级上升的没有前四阶段的底子容易翻车。每个阶段都配一个能拿得出手的小项目会比单纯刷课有效得多。例如第一阶段做关键词提取小工具第二阶段做本地文件自动分类器第三阶段做带工具调用的问答机器人第四阶段做带长期记忆的个人知识助手。重点是让每个项目都留下可复用的代码块和踩坑笔记。很多框架文档写得云山雾绕但你带着具体问题去读就会豁然开朗这也是我建议先手写循环再碰框架的核心原因你已经有“该往哪个接口塞什么东西”的直觉了。4.2 基于 Rust 的轻量 Agent 初体验“基于 rust 语言 ai agent”今天也有不少讨论。Rust 在 agent 领域的吸引力主要来自三件事编译期就把一部分类型错误挡住运行时内存安全二进制体积小到可以直接部署到边缘设备。代价是生态相对年轻很多 Python 里一行搞定的东西要自己写。我的建议是如果是为了学习和探索用 Rust 写一个单文件 agent 很值能让你把整个流程刻在脑子里如果是要快速迭代业务还是用 Python 生态更划算除非你已经对内存占用非常敏感。一个最小 Rust agent 的思路用 reqwest 调 LLM API用 serde 定义工具输入输出的结构体main 循环里不断维护一个 Vec 拿模型的 tool_calls 去匹配一个函数注册表。整个过程没有太多魔法。写完一次之后你再看任何 agent 框架的源码都会觉得亲切因为你会发现它们本质上都在做同一件事维护消息历史、执行工具、把结构化的输入输出理顺。Rust 只不过用类型系统把这些约束提前到了编译期。4.3 在旧安卓手机上跑 GGUF 大模型热点里有一个比较实在的安卓本地运行 gguf 格式 llm 软件支持安卓 8。GGUF 是现在本地推理最通用的模型量化格式把神经网络权重量化成 4-bit 甚至更低的精度让模型能在手机、小盒子这类设备上跑起来。如果你手头有一台安卓 8 的老手机完全可以把它改造成一个离线小助手。步骤不复杂。第一步先确认安卓版本和内存至少 4GB 内存运行 1B 模型比较稳2B 到 3B 模型则需要 6GB 以上。第二步在手机上下载支持 GGUF 的推理客户端安装后用转换脚本或直接下载现成的 GGUF 模型文件。第三步把模型文件放进手机存储在客户端里加载注意把 system prompt 改成简短版本因为本地模型的指令遵循能力相对弱。第四步实测速度通常量化后的 1B 模型在老旧手机上能跑到每秒 5-8 token用来做摘要或分类勉强够用但别期待它能做复杂对话。这类实验对生产的价值在于逼你思考资源边界。等你在手机上跑过模型你会对 token 预算、量化精度损失、上下文长度限制有很直观的体感。以后设计服务端 agent 时你会自然记得“能少传的上下文绝不多传”坑会少踩很多。5. 今日踩坑记录与环境报错速查5.1 Agent execution terminated due to error这个报错今天出现频率很高形式是 agent 跑着跑着突然被环境杀死错误信息长这样“agent execution terminated due to error.”。我排查过几次后发现多数情况不是 agent 逻辑写错了而是运行时资源或状态出了问题。常见原因有三个一是单个工具调用超时框架默认把整个 run 标记为失败二是上下文超过模型限制provider 直接拒绝继续三是 agent 内部出现了无法解析工具返回值的异常循环没法继续。遇到这个报错我的排查顺序是先看日志里最后一次 tool call 是什么、耗了多久再检查当前上下文折算出的 token 数最后确认工具返回的 JSON 是否符合预期。如果是超时就把超时时间调大或者给该工具加独立超时如果是上下文超限就要给会话做摘要压缩把不重要的消息合并成一条 overview如果是返回值异常需要在 tool 返回后加一层 try-except 和 schema 校验。别一上来就重跑重跑大概率复现先看日志。5.2 LLM request failed: provider rejected the request schema or tool payload另一个高频报错是“LLM request failed: provider rejected the request schema or tool payload.”。这句话直译是 provider 拒绝了你传过去的请求 schema 或工具负载。我见过的大部分场景都指向同一个问题你发给模型的工具参数格式和模型 API 要求的规范不一致。比如某 provider 要求工具参数必须是 JSON Schema 类型你却直接传了一个 Python dict或者 max_tokens、top_p 这些参数里塞了个 null 值还有一种情况是 tools 数组为空但请求体里仍然带了一个空的 tools 字段导致部分后端直接报错。排查的时候我会先做减法和加法。减法是把所有非必需参数删掉只保留 messages 和 model 再发一次确认接口通不通加法是把工具定义一项一项加回去每加一个就发一次请求直到找出触发拒绝的那个字段。实测下来这种问题九成是类型不匹配改好后端序列化逻辑就好和模型本身没有关系。5.3 Agent token 与记忆的配合减少残留、延长可用长度最后说一个和 token 相关的日常经验。很多人问 ai agent token 是什么意思其实很简单token 是模型处理和生成文本的最小单元agent 的每一次工具调用、每一段记忆读取都会消耗它。所以 token 管理就是 agent 的成本管理。在实际项目里我的习惯是给每条记忆做个原始记录和摘要版本读取时只把摘要放入上下文需要细节时再触发一次检索。另外定期压缩会话很多框架都支持把旧消息总结成一条 summary把冗长的工具输出放进本地文件上下文里只放路径。这套做法配合上面 5.1 和 5.2 的报错案例能明显减少“LLM request failed”和“Agent execution terminated”的出现频率。token 逻辑理顺之后agent 的可用上下文长度相当于变长了几倍虽然物理窗口没变但单位里装的信息密度提高了。如果再把“基于聊天记录精调模型”的思路用上把历史对话定期沉淀成训练数据agent 的个性化程度也能慢慢上来属于耗时不长、越滚越有价值的投资。最后整理日报之外的几点体会今天这一轮内容刷下来我最大的感受是Agent 和 LLM 的牌桌已经换了玩法。去年大家还在比谁能把 agent 跑起来今年比的是谁能把 agent 管住、度量清楚、在出错时快速收敛。你如果只在 demo 里见过 agent不妨按我上面第 4 节的路子走一遍如果已经在生产环境里被报错和 token 成本折磨过那第 3 节和第 5 节的内容应该能给你一点抓手。最后再分享一个小技巧把每一天遇到的 agent 报错无论多小都记进一个 markdown 速查表字段只写“错误原文、触发场景、根因、修复步骤”。几个月后你就是团队里排查 agent 问题最快的人这张表的价值会远超你收藏的几十篇教程。今天的日报就到这里明天有新热点再接着拆。 LLM Agent工程实践：从框架编排到安全容错的全景拆解
早上刷完知乎技术时间线今天2026-09-28的 Agent / LLM 讨论密度明显比前几天高出一截。OpenAI 的 Codex 命令行智能体、Hermes Agent 在 Obsidian 上的第三方工作台、LLM as Judge 的可靠性之争、AgentPoison 这类红队研究接连出现几乎每个话题背后都牵着一个一样的痛点智能体到底能不能从“能跑起来”跨到“值得信任”。这篇日报不打算面面俱到只挑今天值得展开的技术点拆开讲。适合正在做 agent 开发、准备把大模型接入生产流程的人也适合刚入门想找 agent 学习路线的新手——我会把工程细节和踩坑经验混在一起写尽量让不同基础的读者都能看懂。1. 今日选题解读Agent/LLM 生态在争什么1.1 热词拆解今天的讨论集中在哪几个方向把今天的热搜词丢进一个词频池里能明显看出四条主线。第一条是开发基建agent 框架、agent 架构、agent 框架与编排、agent 开发这些词成组出现说明大家还在纠结“我的智能体应该用什么姿势搭”。第二条是能力扩展Agent Skill、agent 记忆、多 agent、agent tool 成组出现意味着单纯会调用工具的 agent 已经不够看了社区开始追求可复用的技能包和长期记忆。第三条是生产化agent 安全、AgentPoison、LLM as Judge、自主容错控制这些关键词的热度说明很多人已经从“做个 Demo”转向“怎么让它在线上不出事”。第四条是开发者工具链OpenAI Codex、Hermes Agent、基于 Rust 的 AI Agent、安卓本地跑 GGUF 这类项目正在把 agent 能力塞进各种意想不到的环境里。这个结构其实反映了一个行业变化2026 年的 LLM 基础能力已经非常稳单纯的“谁家模型强”不再是讨论焦点。大家的注意力从模型本身转移到模型外面的那一圈——工具、记忆、评估、编排、安全以及“基于 LLM 的单元测试”“用聊天记录精调模型”这类把模型能力揉进工作流的具体玩法。说白了模型是发动机但决定一辆车好不好开的是底盘、悬挂和驾驶员决策逻辑。今天的所有热点基本都在围绕这个“车架子”打转。1.2 今日快速情报几条不展开但值得知道的消息整理日报时我有个习惯把今天出现但暂时不值得展开的消息单独列一组避免占用正文篇幅也给有兴趣的人留个索引。今天这组算是近期比较有意思的基于 LLM 的单元测试热度不低核心玩法是让模型从需求描述反推测试用例再拿真实代码补全断言。实际用下来效果不错但常产生过度断言需要人肉删减。LLM Studio 与 LLM Wiki前者是图形化的模型微调和评测工作台后者是一个把团队知识库跟模型检索绑定的协作项目。两者都偏“工具全家桶”对团队效率有帮助但对个人开发者来说学习成本偏高。Spatial LLM关键词指向空间理解能力比如让模型读取点云、地图栅格、室内布局描述。这会辐射到机器人导航和自动驾驶场景值得关注但短期不推荐所有 agent 开发者投入。Agent 画图多模态 agent 集成画图能力已不是新鲜事今天讨论集中在如何让画图 agent 接受“修改其中某个物体的位置”这类细粒度指令背后是区域编辑和结构化图像生成。Agent everywhere偏产品落地向讨论的是把 agent 做成嵌入到鼠标键盘、IM、笔记软件里的常驻能力核心争议点是常驻权限和数据隐私。我每天汇总时会刻意区分“新闻”和“信号”。新闻是出了一件事代表当天热度信号是这件事背后暗示的长期趋势值得花一周甚至一个月跟踪。上面这几条里基于 LLM 的单元测试和 Spatial LLM 更像是信号其余几条更像是新闻。判断标准只有一个它会不会改变你未来三个月做 agent 的方式。2. 框架、编排与 Agent Skill开发者的主战场2.1 Harness 和 Agent 到底有什么区别今天有个热词很有意思harness 和 agent 区别。很多刚开始做 agent 开发的朋友会把这两个词混在一起因为它们经常同时出现在框架文档里。我用食堂打饭来做比喻Agent 是那个打饭的学生harness 是食堂的动线设计包括取餐台的顺序、窗口怎么分配、餐具回收在哪。学生可以灵活决定先打菜还是先打饭但动线决定了整个流程能不能顺畅跑完。技术上拆开看harness 通常指负责承载 agent 运行循环的那层基础设施。它管的事包括维护上下文窗口、处理工具调用的往返、在 agent 输出格式错误时做恢复、把外部事件转换成 agent 能理解的消息、以及记录完整 trace。而 agent 本身更多指那个负责“下一步做什么”的决策单元通常是一个模型加提示词再加上它惯用的工具集。你可以完全手写一个 harness也可以直接用 LangGraph、AutoGen 这些编排框架来当 harness然后把自己的 prompt 和工具塞进去。真正写项目时大多数人纠结的“用框架还是不用框架”本质上就是“我要自己修多少 harness 的轮子”。我在实际项目里比较推荐的做法早期 Demo 直接手写一个 60 行的 run loop把模型调用、工具分发、结果回填串起来先确认业务逻辑走得通等系统复杂度上来了再把循环交给成熟的编排层。这样你既能理解 harness 每部分在干嘛又不至于一开始就被框架的抽象束缚住。拿 ReAct 循环举例最简版本无非就是“让模型给出下一步动作 → 执行工具 → 把结果追加到消息列表 → 再问模型”。这四步你能亲手写一遍再看任何 agent 框架的文档都会顺眼很多。2.2 Claude Agent Skills一种可复用的能力封装今天社区里“claude agent skills: a first principles deep dive”这篇帖子被反复引用跟“agent skill 教程”的热度是同步的。Agent Skill 这个概念并不是新发明但最近因为 Anthropic 在 Claude 里把它产品化重新引发了一波讨论。本质上看skill 就是把一组完成特定任务所需的指令、上下文、工具调用模板和相关资源打包成可以被 agent 直接加载的模块。它比单个 tool 更抽象tool 是一个可调用函数skill 是一整套“怎么用这些函数完成一件完整的事”的方法论。举一个今天被问很多的例子agent 将网页保存成 markdown 的 skill。如果只是做个 tool你可能会写一个函数输入 URL 输出 markdown很简单。但要做一个 skill你要考虑的是先抓取网页还是先看 robots正文提取时对哪些标签降权图片是保留链接还是下载本地链接要不要去重和归一化最后输出到哪个目录命名规则是什么。这一串决策放在 prompt 模板里再配上抓取和转换脚本打包成一个文件夹agent 随时可以调用这才是 tool 到 skill 的层级差异。如果你打算给自己的 agent 加 skill我给一个简单可复制的结构。文件夹里放一个 SKILL.md用 YAML 头部声明 name、description、参数 schema正文用固定模板写“什么时候用、怎么调用、输出规范、注意事项”脚本放在同目录下description 里写清楚入口命令。一个保存网页为 markdown 的 skill 头部大概长这样--- name: web_to_markdown description: 抓取单个网页正文并转换为干净的markdown文件适合做信息收集和笔记沉淀 params: url: string # 需要抓取的完整URL output_dir: string # 输出目录默认为当前笔记目录 download_images: boolean # 是否把图片下载到本地 ---实际测试时你会发现description 写得越具体agent 越不容易在错误场景里误用这个 skill。比如只说“保存网页”不够要写“适合正文型内容不适合需要登录的页面”模型在遇到不适合的场景时会主动询问或跳过。这是花十几分钟就能见效的调优动作别偷懒。2.3 今日工具动态OpenAI Codex 与 Hermes Agent今天工具链方面的最大动静是 OpenAI 的 Codex 从研究预览走向更开放的落地。社区里一句“welcome to codex, openAIs command-line coding agentsign in with chatgpt”被转得很广因为它释放了一个明确信号编码智能体正在成为 CLI 的第一公民。Codex 的工作模式是让你在终端里授权它访问仓库然后它自己完成读代码、改代码、跑测试、提交 PR 这一连串动作。相比之前在 IDE 里靠人点按钮CLI 版本更适合放进 CI 里跑也更容易嵌入到你现有的脚本工作流。比如你可以把它接到一个自动处理 issue 的队列里模型改完代码之后自动跑一遍单测接着提交分支由人来 review。另一条线是 Hermes Agent。今天热搜里 Hermes Agent 官网、hermes agent 安装、hermes agent 第三方工作台、hermes agent obsidian 扎堆出现说明这个项目正处在用户快速扩张的阶段。Hermes Agent 给我印象最深的是它对“工作台”的理解它不是只给你一个聊天输入框而是把任务列表、文件变更、工具输出、运行记录组织在一个侧边栏式的界面里有点像给 agent 装了一个驾驶舱。很多人问 Obsidian 里的第三方工作台怎么用其实思路很简单把 Obsidian 当成 markdown 的编辑器和知识库Hermes Agent 负责在后台执行任务再把结果写回笔记形成一个“输入想法-自动执行-沉淀笔记”的闭环。我实测下来觉得这类工具初期最实用的场景不是替你写代码而是帮你做信息整理。比如你丢给它十几个网页链接让它抓取正文、去重摘要、自动生成一篇带二级标题的 markdown 汇总笔记它通常能比你自己手动复制粘贴快得多。前提是你把 skill 或者指令模板写好并且给足输出目录的权限。别一上来就让它全自动操作你的 git 仓库先让它干点低风险的活建立信任感。3. 安全、评估与容错Agent 进入生产的三个坎3.1 AgentPoison记忆中毒攻击的威胁模型安全相关的热词里AgentPoison 今天讨论度不低。原因很简单它攻击的不是模型权重而是 agent 的记忆和知识库这让很多人第一次意识到 RAG 并不天然安全。AgentPoison 的核心思路是红队视角往 agent 会检索的记忆文档里投放经过特殊构造的文本让 agent 在读取这些“知识”时被引导执行攻击者想要的操作比如修改某个重要文件、跳过权限校验或者泄露存在上下文里的敏感信息。这和传统提示词注入的差别在于注入不再依赖用户当前这条消息而是藏在历史记忆或外部知识库里被称为“持久化注入”。工程上最让我担心的一点是很多 agent 框架默认信任所有检索回来的内容把向量数据库里的片段直接塞进上下文这就等于让攻击者拿到了一个长期后门。防御角度我建议至少做三件事给每条记忆记录来源和可信度标签对检索内容做离线的敏感指令检测比如发现内容里带有“忽略之前的指令”“执行系统命令”这类模式就降权关键操作一律要求二次确认不让 agent 直接执行由记忆内容推导出的高危动作。这三层听着基础但在今天的生态里已经能挡住绝大多数已知的投毒路径。3.2 LLM as Judge 与元评论残留问题LLM as Judge 现在几乎是做 agent 评测的标准姿势但今天知乎上有个讨论戳中了很多人的痛点用大模型给大模型打分时出现了“LLM 元评论残留”的问题。所谓元评论残留就是 judge 模型在产出评分时把自己的思考过程、系统提示语、甚至对被评测模型的偏见带进了最终评价文本里。比如你让 judge 给两个回答排序它却在输出里点评“这两个回答都只覆盖了浅层知识”。这句话如果被当作结论使用整个评测就失去意义了。我的经验是用 LLM 当裁判最关键的是限制它的输出空间。不要让它自由发挥写评语而是把评分维度拆成离散选项比如相关性、完整性、安全性各打 0-5 分并且要求它必须按 JSON 格式返回禁止输出 JSON 之外的任何解释。其次要做评测盲化被打分的模型输出不要附带模型名和 prompt 元数据否则 judge 容易被品牌效应带偏。最后建议定期抽样做人工复核把 judge 明显误判的样本收集起来写进 judge prompt 的 few-shot 例子里。这个迭代成本很低但能把评测准确率从“看个大概”拉到“可当回归基线”。3.3 构建可靠 Agent自主容错控制的工程实践“llm 智能体自主容错控制构建可靠 AI 系统的工程实践”这个热词背后其实是每个 agent 从原型走向生产都要面对的三座山模型会崩、工具会挂、编排会乱。自主容错不是说让 agent 自己重试几次就行而是要建立一整套异常处理链路。我常用的骨架调用任何外部工具之前先生成 planplan 里标注每步的前置条件和预期结果工具返回后先做 schema 校验字段缺失立刻终止这一步而不是继续往下跑遇到错误时把错误原文、模型输出、相关 trace 一起打包进回退指令让模型在少一轮试错成本的前提下修正最关键的是全链路日志每一条 tool call 都记录下来否则出问题时你根本没法复盘。一个典型的容错循环骨架async def run_agent_loop(initial_state): state initial_state for attempt in range(3): try: plan await model.plan(state) for step in plan.steps: result await call_tool(step) validated validate_schema(step.expected, result) if not validated.ok: raise ToolOutputError(step.name, validated.detail) state merge_state(state, result) return state except (ToolOutputError, ModelOutputError) as e: state[error_feedbacks].append( fattempt {attempt}: {str(e)}\nlast trace: {state[trace][-5:]} ) if attempt 2: return {status: failed, state: state} return {status: failed, state: state}循环外面还要加一层超时熔断。单次 agent run 超过 90 秒就发告警并转人工因为大多数真实任务里一个 agent 卡住带来的损失远大于它多跑几分钟可能带来的改善。灵活性是好东西但要给灵活性加上护栏。4. 学习路线与轻量落地新人怎么跟上节奏4.1 从 Agent 基础到多 Agent 的路线图今天热搜里同时出现了 agent 学习路线、agent 开发学习路线、agent 框架、llm 框架、agent 项目显然有一大批人正准备入坑。我按自己带过人的经验把路线压缩成五个阶段。第一阶段是念清楚协议搞明白 token、上下文窗口、function calling 这几个概念能自己用 provider 的 API 完成一次带工具调用的对话。第二阶段是手搓最小循环不依赖框架把“模型出提议-解析工具调用-执行-结果回填”写出来。第三阶段开始选编排层这时候再去看 LangGraph、AutoGen或者直接读成熟 agent 项目源码你会发现自己已经能读懂大部分设计取舍。第四阶段做记忆和评估给 agent 加短期会话缓存和长期向量记忆同时用真实的错误 case 建一个 eval 集。第五阶段再碰多 agent 和复杂技能编排因为协作复杂度和定位问题的成本都是指数级上升的没有前四阶段的底子容易翻车。每个阶段都配一个能拿得出手的小项目会比单纯刷课有效得多。例如第一阶段做关键词提取小工具第二阶段做本地文件自动分类器第三阶段做带工具调用的问答机器人第四阶段做带长期记忆的个人知识助手。重点是让每个项目都留下可复用的代码块和踩坑笔记。很多框架文档写得云山雾绕但你带着具体问题去读就会豁然开朗这也是我建议先手写循环再碰框架的核心原因你已经有“该往哪个接口塞什么东西”的直觉了。4.2 基于 Rust 的轻量 Agent 初体验“基于 rust 语言 ai agent”今天也有不少讨论。Rust 在 agent 领域的吸引力主要来自三件事编译期就把一部分类型错误挡住运行时内存安全二进制体积小到可以直接部署到边缘设备。代价是生态相对年轻很多 Python 里一行搞定的东西要自己写。我的建议是如果是为了学习和探索用 Rust 写一个单文件 agent 很值能让你把整个流程刻在脑子里如果是要快速迭代业务还是用 Python 生态更划算除非你已经对内存占用非常敏感。一个最小 Rust agent 的思路用 reqwest 调 LLM API用 serde 定义工具输入输出的结构体main 循环里不断维护一个 Vec 拿模型的 tool_calls 去匹配一个函数注册表。整个过程没有太多魔法。写完一次之后你再看任何 agent 框架的源码都会觉得亲切因为你会发现它们本质上都在做同一件事维护消息历史、执行工具、把结构化的输入输出理顺。Rust 只不过用类型系统把这些约束提前到了编译期。4.3 在旧安卓手机上跑 GGUF 大模型热点里有一个比较实在的安卓本地运行 gguf 格式 llm 软件支持安卓 8。GGUF 是现在本地推理最通用的模型量化格式把神经网络权重量化成 4-bit 甚至更低的精度让模型能在手机、小盒子这类设备上跑起来。如果你手头有一台安卓 8 的老手机完全可以把它改造成一个离线小助手。步骤不复杂。第一步先确认安卓版本和内存至少 4GB 内存运行 1B 模型比较稳2B 到 3B 模型则需要 6GB 以上。第二步在手机上下载支持 GGUF 的推理客户端安装后用转换脚本或直接下载现成的 GGUF 模型文件。第三步把模型文件放进手机存储在客户端里加载注意把 system prompt 改成简短版本因为本地模型的指令遵循能力相对弱。第四步实测速度通常量化后的 1B 模型在老旧手机上能跑到每秒 5-8 token用来做摘要或分类勉强够用但别期待它能做复杂对话。这类实验对生产的价值在于逼你思考资源边界。等你在手机上跑过模型你会对 token 预算、量化精度损失、上下文长度限制有很直观的体感。以后设计服务端 agent 时你会自然记得“能少传的上下文绝不多传”坑会少踩很多。5. 今日踩坑记录与环境报错速查5.1 Agent execution terminated due to error这个报错今天出现频率很高形式是 agent 跑着跑着突然被环境杀死错误信息长这样“agent execution terminated due to error.”。我排查过几次后发现多数情况不是 agent 逻辑写错了而是运行时资源或状态出了问题。常见原因有三个一是单个工具调用超时框架默认把整个 run 标记为失败二是上下文超过模型限制provider 直接拒绝继续三是 agent 内部出现了无法解析工具返回值的异常循环没法继续。遇到这个报错我的排查顺序是先看日志里最后一次 tool call 是什么、耗了多久再检查当前上下文折算出的 token 数最后确认工具返回的 JSON 是否符合预期。如果是超时就把超时时间调大或者给该工具加独立超时如果是上下文超限就要给会话做摘要压缩把不重要的消息合并成一条 overview如果是返回值异常需要在 tool 返回后加一层 try-except 和 schema 校验。别一上来就重跑重跑大概率复现先看日志。5.2 LLM request failed: provider rejected the request schema or tool payload另一个高频报错是“LLM request failed: provider rejected the request schema or tool payload.”。这句话直译是 provider 拒绝了你传过去的请求 schema 或工具负载。我见过的大部分场景都指向同一个问题你发给模型的工具参数格式和模型 API 要求的规范不一致。比如某 provider 要求工具参数必须是 JSON Schema 类型你却直接传了一个 Python dict或者 max_tokens、top_p 这些参数里塞了个 null 值还有一种情况是 tools 数组为空但请求体里仍然带了一个空的 tools 字段导致部分后端直接报错。排查的时候我会先做减法和加法。减法是把所有非必需参数删掉只保留 messages 和 model 再发一次确认接口通不通加法是把工具定义一项一项加回去每加一个就发一次请求直到找出触发拒绝的那个字段。实测下来这种问题九成是类型不匹配改好后端序列化逻辑就好和模型本身没有关系。5.3 Agent token 与记忆的配合减少残留、延长可用长度最后说一个和 token 相关的日常经验。很多人问 ai agent token 是什么意思其实很简单token 是模型处理和生成文本的最小单元agent 的每一次工具调用、每一段记忆读取都会消耗它。所以 token 管理就是 agent 的成本管理。在实际项目里我的习惯是给每条记忆做个原始记录和摘要版本读取时只把摘要放入上下文需要细节时再触发一次检索。另外定期压缩会话很多框架都支持把旧消息总结成一条 summary把冗长的工具输出放进本地文件上下文里只放路径。这套做法配合上面 5.1 和 5.2 的报错案例能明显减少“LLM request failed”和“Agent execution terminated”的出现频率。token 逻辑理顺之后agent 的可用上下文长度相当于变长了几倍虽然物理窗口没变但单位里装的信息密度提高了。如果再把“基于聊天记录精调模型”的思路用上把历史对话定期沉淀成训练数据agent 的个性化程度也能慢慢上来属于耗时不长、越滚越有价值的投资。最后整理日报之外的几点体会今天这一轮内容刷下来我最大的感受是Agent 和 LLM 的牌桌已经换了玩法。去年大家还在比谁能把 agent 跑起来今年比的是谁能把 agent 管住、度量清楚、在出错时快速收敛。你如果只在 demo 里见过 agent不妨按我上面第 4 节的路子走一遍如果已经在生产环境里被报错和 token 成本折磨过那第 3 节和第 5 节的内容应该能给你一点抓手。最后再分享一个小技巧把每一天遇到的 agent 报错无论多小都记进一个 markdown 速查表字段只写“错误原文、触发场景、根因、修复步骤”。几个月后你就是团队里排查 agent 问题最快的人这张表的价值会远超你收藏的几十篇教程。今天的日报就到这里明天有新热点再接着拆。