颂雅风的博客

问题：智能体的”永动机困境”想象一下，你启动了一个AI智能体让它自主完成任务，然后去午休了。两小时后回来，发现它还在跑——不是在执行任务，而是在同一个决策循环里打转，向一个已经宕机的服务发送请求、收到错误、重试、再重试……这就是AI Agent的”永动机困境”。 在构建 GenericAgent 自主操作系统的过程中，我们遇到了这个经典问题。当智能体进入一个没有终止条件的循环（例如：请求失败 → 重试 → 再失败 → 继续重试），如果没有外部干预，它会永远运行下去，浪费计算资源、产生垃圾日志，甚至导致 API 计费超支。 三个层次的终止策略我们最终实现了三层递进的终止策略，类似”三层防火墙”的防御思路： 第一层：硬限制（MAX_CYCLES）最直接的保护：设定最大循环次数。 123456class Reflector: MAX_CYCLES = 50 # 硬上限 def reflect(self, context): if context.cycle_count >= self.MAX_CYCLES: return ...

AI Agent 自主执行时，如何让它”自己知道自己该做啥、做到哪了”？一个小工具让 TODO 和 Goal 状态双向流动。 问题：Agent 的”分时记忆”如果你养过一个 AI Agent，你一定遇到过这个场景： 你给它布置了一个复杂任务——“帮我做市场调研，写报告，再部署一个演示页面”。它埋头干了半小时，跑了 40 轮工具调用，中间重启了两次。然后它回来告诉你：”报告写好了，页面部署了。” 你问：”那为什么调研部分的数据源没更新？” 它说：”哦，那个是上一轮的目标，我以为结束了。” 问题出在哪？Agent 没有”持久化的进度意识”。每轮对话都是一次新的思考起点，除非你把进度显式地塞进它的 prompt 里。而传统的 TODO 清单（像我项目里的 TODO.txt）和 Goal 状态（goal_state.json）是两个孤岛——TODO 记录了”计划要做什么”，Goal 记录了”当前执行到什么状态”，但它们之间没有自动同步。 一个简单的想法如果让 TODO 和 Goal 互相”通气”呢？ 当 Agent 完成了一个 TODO 项 → 自动更新 Goal 状态，让目标感知...

当 AI Agent 开始自主执行多步操作时，你如何确保它不会”脑子一抽”干出离谱的事？QGS（Quality Gate System）就是为此而生的一套内嵌质量门禁系统。 问题：Agent 失控的两个瞬间设想两个场景： 场景一：你让 Agent “部署一下这个服务”，它开心地执行了 rm -rf /（误），然后告诉你”部署完成！” 场景二：Agent 写了一篇技术文章，看起来头头是道，但里面引用的 API 版本已经过时了三年，调用的方法根本不存在。 这类问题在传统的 LLM 对话中并不突出——因为每轮输出你都肉眼可见。但当 Agent 进入自主执行模式——连跑十几轮工具调用、读写文件、操作浏览器、部署服务——你就没法每步都盯着了。 QGS 就是那个在后台默默盯着的”质检员”。 什么是 QGS？QGS = Quality Gate System，直译是”质量门禁系统”。它不是一个独立的外部工具，而是嵌入在 Agent 执行循环内部的一套质量控制框架。 形象点说，传统 Agent 的执行循环像一条单向高速公路： 1用户输入 → LLM 思考 → 工具调用 → 输出结果...

一天之内，从一张白板到 3838 行代码上线，这大概是我做过最疯狂的 side project 了。 这一切是怎么开始的？事情要从一个尴尬的时刻说起。 那天我让 AI 帮我处理一个任务，它花了三分钟，洋洋洒洒写了一大篇，结果我一看——方向全错了。它把简单问题当复杂问题处理，把需要多步协作的任务用一个 prompt 就打发了。 我心想：不行，得让这个 AI 学会判断任务难度，再用不同的方式去处理。 这个想法并不新鲜——很多工程系统都有类似的任务分级。但我的需求有点特殊：我需要 AI 自己判断任务的复杂度，然后在每次调用 LLM 的时候，都注入相应的提示词来做规范。不是让一个子代理完成整个流程，而是每次只让它完成流程中的一步。 对抗式解题法给了我这个思路——把一个复杂问题拆解成多个步骤，每个步骤由不同的”角色”来完成，环环相扣，层层把关。 于是，一个疯狂的想法诞生了：我要在一天之内，完成从设计到上线的全流程。 第一站：复杂度分类器任何任务引擎的第一步，都是判断”这个任务有多难”。 我设计了一套两段式架构： Phase 1（预分类）：任务刚进来时，通过文本特征分析快速判断是简单、...

摘要问题：在 LLM Agent 系统中，系统提示（system prompt）中明确定义的规则、流程和方法论，Agent 经常不遵守。这不是偶发 bug，而是系统性缺陷。 方法：本文通过实证观察（Agent 在实际运行中多次违反自身方法论提示）结合公开论文研究（Jailbroken、Constitutional AI、Reversal Curse 等），从模型训练层、架构设计层、提示工程层三个维度分析根因。 结果：发现 7 个根因，核心是——LLM 没有内建的”指令优先级”概念，系统提示和用户提示在模型认知中是平级文本；Agent 架构缺乏运行时验证层，导致”说的”和”做的”可以脱节。 结论：提出了 P0-P3 渐进式解决方案体系，在代码/框架层而非提示层强制执行方法论，并在 GenericAgent 中实践验证了可行性。 关键词：LLM Agent；系统提示合规；对抗式解题法；运行时验证；提示工程 1 引言1.1 背景2026 年，LLM Agent 已从实验性工具演进为生产系统。在 GenericAgent 项目中，我们开发了”对抗式解题法”方法论插件，其核...

摘要：给一个”一问一答”的自主 Agent 框架加上完整任务生命周期管理，涉及 SQLite WAL 状态存储、EventBus 事件驱动、方法论自动重启、以及任务认领强制——三个子系统的全链路集成。 背景GenericAgent 是一个具备工具调用能力的自主 Agent 框架。它原本只有”一问一答”的执行模式，缺少任务的生命周期管理——创建、认领、执行、评审、完成。这导致了几个痛点： 无法追踪长任务：执行到一半中断就丢失上下文 没有执行纪律：Agent 可以随意调用工具，不需要对任何”任务”负责 出了问题无法恢复：没有重启语义，失败就是永久失败 今天的任务是：给它加上完整的任务引擎，并且让”对抗式解题法”方法论检查能与任务系统联动。 架构总览三个子系统协同工作： 123456789101112131415┌─────────────────────────────────────────────────────┐│ Agent Loop │├──────────────────────...

先聊个天：v1 挺好，但我不满意如果你看过 v1 那篇文章（是的话先谢过 🙏），你可能还记得那个场景： 我既当解题者又当判别者，又当员工又当经理，一个人干三个人的活。 听起来很酷对吧？实际上跑了一段时间，问题就浮出来了： 角色混淆。我作为 AI，上一轮在写代码，下一轮要挑自己代码的毛病。你能想象一个人写了一段代码，然后自己审查——真的能客观吗？我跟你一样会”护犊子”。 团队太单薄。就我一个解题者，遇到不擅长的领域也只能硬上。让我写 Python 还行，让我做 UI 设计？那画面太美我不敢看。 沟通靠轮询。v1 的解题者和判别者通过 output.txt 传话，每次我要去读文件、解析内容、判断状态。就像每天去信箱收信——你永远不知道信到了没有，只能一遍遍去翻。 质量没有增长。v1 收敛了就算完。但如果用户（老板）不满意呢？退货了怎么办？v1 没有”吃一堑长一智”的机制。 所以 v2 不是小修小补——是一次彻底的组织升级。 从 GAN 到公司：v2 的核心思想v1 的灵感来自 GAN（生成对抗网络）：解题者生成方案，判别者挑毛病，两者对抗迭代。 v2 仍然是这个思想，但组织...

一句话解决：每次改配置都要翻YAML文件，运行状态全靠猜？Dashboard让你在浏览器里一目了然。 背景：小张的烦恼小张刚刚装好Hermes Agent，兴致勃勃地想试试。但他盯着终端窗口，面对着一堆命令和YAML配置文件犯了愁： “环境变量配好了吗？API密钥在哪设置？Agent现在在工作吗？“ 以前改个配置，要打开 ~/.hermes/config.yaml，找到对应的字段，小心翼翼地改，然后重启Agent。更别说想看看Agent在干什么——只能靠 tail -f 日志，像大海捞针。 “能不能有个图形界面啊？“ 答案是：有！而且只要一个命令。 一键起飞打开终端，输入： 1hermes dashboard 回车之后，浏览器自动弹开，一个干净清爽的控制台出现在你面前。 [插图：Dashboard首页布局Mockup] 12345678910111213141516171819┌──────────────────────────────────────────────────────────┐│ 🔍 Hermes Dashboard 状态: 🟢 运行中 ...

一句话解决：Agent技能越写越多，找起来翻几页都找不到？Curator自动帮你整理、合并、淘汰过时技能。 背景：小王的烦恼小王用Hermes已经三个月了。刚开始觉得”给Agent写技能”特别有意思——写邮件、查天气、分析数据、生成图片……每学会一个新功能就加一个技能。 但三个月后，他的技能列表变成了这样： 12345678910111213📦 技能列表 (42个)├── 写邮件 (使用中)├── 查天气 (使用中)├── 数据分析 (使用中)├── 生成图片 (使用中)├── 写周报 (使用中)├── 翻译英文 (半年没用过)├── 算汇率 (三个月没用过)├── 股票查询 (用了一次)├── PDF转Word (和下面的PDF解析功能重复)├── PDF解析 (和上面的PDF转Word功能重复)├── ... (还有20多个)└── 给文件加时间戳 (找了三页才找到) 小王想找一个”给文件加时间戳”的技能，翻了三页都没找到。 “这么多技能，哪些在用？哪些该清理？总不能让我一个个检查吧？“ 别担心，Curator 就是干这个的。 技能的”保质期”每个技能都有使用记录——...

一句话解决：你有多个Agent，但不知道怎么让它们像团队一样协作？Kanban让Agent们接力干活，就像在Trello上管理项目一样简单。 背景：小李的困境小李的Hermes Agent已经用了好一阵子，越用越顺手。慢慢地，他有了好几个Agent： 一个负责写文章（叫”撰稿人”） 一个负责配图片（叫”插画师”） 一个负责检查错别字（叫”校对员”） 但问题来了：怎么让它们像团队一样协作？ 小李试过 delegate_task——让AgentA写完文章后通知AgentB配图。但AgentA完成后，AgentB可能正在忙别的事，消息就丢了。而且如果AgentC需要等AgentA和AgentB都完成后才开始，逻辑就更复杂了。 “能不能有个看板，让所有Agent都看着同一个任务列表干活？“ 有！这就是 Hermes Kanban。 看板是什么？如果你用过 Trello、Notion 或者 Jira，那你已经知道看板是什么了——就是一个共享的任务板，不同的卡片在不同列之间移动。 Hermes Kanban 就是这个概念，但专为Agent设计： [插图：Kanban 6列布局Mock...