AI Agent

我现在的「AI 工作台」：codex + Cindy + openclaw + kilo 最近被朋友反复问同一个问题：你这四个 AI 工具到底是怎么分工的？codex、Cindy、openclaw、kilo，光听名字确实都像"AI 助手"，凭什么不全用同一个？我自己也花了不少时间才把这套组合理顺。这篇文章只讲一件小事：在我手里，这四个工具分别占住了不同的工作位，缺谁我都会别扭。 我写代码的"主驾"是 codex。这里的"主驾"很具体：跨多文件、需要持续迭代、上下文一旦断了就接不回去的那一类项目。我把 codex 一直挂着，它不像一个"一次性问答工具"，更像一个能跟项目同呼吸的搭档——它看过的文件、改过的 diff、跑过的命令，会变成下一轮决策的依据。规矩只有三条：把 codex 当"项目主驾"而不是"问答工具"，给它持续的事实而不是一次性的提示；用里程碑切会话，长会话里它会慢慢漂移，里程碑一过就 reset，让它从干净的事实开始；看 diff 而不是看回答，它给的"通过"只是参考，最终那一下"合不合"必须人来定。 Cindy 站的是另一个位。她不只是"另一个 AI"，更像是四个工具之间的调度位。一半的时间我在做办公——写周报、整会议纪要、做汇报材料、起草对外的邮件——这摊事她是我的主力。但更让我离不开的，是她无缝衔接 Pi、codex、Claude的能力。我经常是这样跑工作流的：先用 Cindy 把需求讲清楚、列好要点；遇到需要长链路推理的，把上下文接力给 Pi；进入真正的工程实施阶段，再接力给 codex；想换一个视角听反馈或做对照，再回到 Cindy 或转 Claude 跑一遍。整条链路的纪律是：办公是基本盘，周报、会议纪要、对外邮件这一摊她是主力；调度是放大器，她和 Pi / codex / Claude 接力，让上下文在工具之间流动，我不用复制粘贴、不用重新解释背景；接力链路过长是陷阱，两到三跳最舒服，再多，信息的损耗就会显出来，必须切回 Cindy 重整。 再往下是 openclaw。它在我这里干的是"不入主线"的杂活。什么叫杂活？一次性脚本、临时数据清洗、批量改个文件名、跑个不痛不痒的小爬虫、把一段音频转成文字、给一张图换个尺寸、临时翻译一段不要求精度的文字——这些事不会上 GitHub、不会进生产、也不会被任何会议引用，但不做又会卡住主线进度。openclaw 就是这种"轻骑兵"，打开就能用、用完就走。规矩是：任务的边界是"不入主线"，都是它的活；价值在"快"和"不打断心流"，不在"严谨"和"可追溯"，别把它的输出直接当交付物；用完就走，它不占心智位，也不抢主线位。 kilo 的角色最简单：在 VSCode 里用的那个。很多写代码的时间是碎片化的——我在 IDE 里写到一个函数、卡住、想问一下；改到一半想确认某个 API 的用法；review 一段刚写的逻辑想找人挑刺。这时候我不想切窗口、不想开新 tab、不想跳出当前文件，kilo 就在侧栏里直接接住。规矩也很简单：位置在 VSCode 侧栏，随手就能用，不切窗口；任务是碎片化的"边写边问"，卡住的函数、API 用法、刚写完的逻辑想挑刺，kilo 就在手边；不要在 kilo 里跑长链路任务，它的定位是"边写边问"，不是"项目级搭档"，那个位是 codex 的。

Go 语言架构｜Google ADK Go 深入拆解：把 Agent 写进 Go 的工程流水线 原文：Agent Development Kit (ADK) for Go 作者：Google ADK Go 团队（Google 官方开源项目维护者） 来源：GitHub，发布于 2025 年 11 月 06 日 我最近重新看了一遍 Google 的 ADK Go。它吸引我的地方，并不是“Go 也有一个 AI 框架”，而是它试图回答一个更实际的问题：一个会调用模型、工具和其他 Agent 的系统，能不能像普通 Go 服务一样被编译、被测试、被部署和被审查？ 这篇文章不打算把官方 API 逐个翻译一遍。我会沿着自己的理解，把 Agent、工具、工作流、协议、状态和上下文串起来，也会特别标出 v1 与 v2 的边界。文中的蓝色表示工具或事实，绿色表示我的实践判断，红色表示容易踩的坑，黄色底色表示可以直接拿去用的做法。 先看 ADK Go 为什么值得单独关注。 我认为，ADK Go 的重点不是证明“Go 比 Python 快”，而是让 Agent 代码进入成熟的软件工程流程。Go 项目已有的编译器、静态检查、单元测试、依赖管理、CI 和容器化能力，都可以继续使用。 ...

学习和理解 OpenAI的Responses：模型调用过程的原子事务？ Responses 的核心价值，不是把接口名称从 Chat Completions 换成了 responses，而是把模型调用从“返回一段文本”升级成了可组合、可追踪、可继续执行的结构化结果。一次调用可以同时产出最终消息、函数调用、内置工具调用和受控的推理摘要；应用不必再把所有信息塞进一段字符串里猜测和解析，而是可以按 item 类型决定下一步动作。 这个变化真正解决的是 Agent 工程里的三个问题：模型做了什么更容易追踪，工具调用怎么接续更清楚，失败后从哪里恢复更具体。最近和同事讨论 OpenAI 的 Responses API，我发现最容易混淆的不是请求怎么发，而是“一次 Response 到底装了什么”。我现在更愿意把它理解成：一次有结构的模型调用记录。它可以成为调试、审计和多轮协作的共同载体，但它不是数据库里的 ACID 事务，也不是默认把完整思维链交给用户。“原子事务”只是一种帮助理解的比喻：工程上真正要记录的是调用 ID、item 类型、工具结果、失败状态和业务幂等关系 ┌─────────────────────────────────────────────────────────┐ │ Responses 协议心智图 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 你发起 ──→ 一次 Response（原子事务） │ │ │ │ │ ├── input （输入） │ │ ├── instructions （系统级设定） │ │ ├── tools （可选能力清单） │ │ │ ├── 内置工具 （web/file/code/MCP）│ │ │ └── 自定义函数 │ │ ├── previous_response_id （状态游标） │ │ └── stream / background （执行模式） │ │ │ │ 服务端返回 ──→ 一个 Response 对象 │ │ │ │ │ └── output[] （异构工件清单） │ │ ├── reasoning （思维证据） │ │ ├── tool_call （动作证据） │ │ │ ├── 入参 │ │ │ └── 结果 │ │ └── message （交付物） │ │ │ └─────────────────────────────────────────────────────────┘ ...

心动公司开源的 Cindy：一个值得交代第一件任务的 AI Agent 参考资料：Cindy——开源、开箱即用的 AI Agent 作者：本文作者（原创体验向解读） 来源：Cindy 官网、GitHub 开源仓库 最近看到 Cindy 时，我的第一反应不是“又一个聊天机器人”，而是：它似乎在认真回答一个更实际的问题——AI 能不能从回答问题，走到把事情做完？ Cindy 是心动公司开源的一款 AI Agent。她把模型、Agent Harness、工具、记忆和工作区组织进桌面端与移动端应用，目标不是陪你聊几句，而是进入真实的项目和软件环境，完成一项可以验收的工作。 这个定位很容易让人兴奋，也很容易让人警惕。毕竟，“全能助手”已经是 AI 产品最常见的宣传词。真正让我感兴趣的，是 Cindy 把开源、可替换模型和人工审查放在了一起：她不要求你把所有东西交给一个黑盒，而是允许你逐步培养、逐步放权。 先把时间点说清楚：截至 2026 年 8 月 20 日，GitHub 上最新的桌面端 Release 是 v0.1.55，发布于 8 月 18 日；移动端版本独立更新。下面这篇不是跑分报告，而是一份上手前的体验判断：重点看看 Cindy 能替你推进什么，以及哪些决定仍然应该留在人手里。 我平时使用 AI 工具时，最容易被打断的并不是写出第一版，而是让第一版真正进入工作流：找到文件、执行命令、处理报错、检查改动，再把结果整理出来。本文也会以这个实际使用场景作为判断 Cindy 的入口。 蓝色高亮表示产品能力，绿色高亮表示我的使用判断，红色高亮表示权限与隐私提醒，黄色高亮表示可以直接尝试的建议。 一、Cindy 解决的不是“不会写”，而是“事情没收尾” 我已经习惯让 AI 写一段代码、改一个函数、解释一个报错。但在实际工作里，一个问答往往只是开始。 一个看似简单的任务，可能包括： 找到正确的项目目录； 阅读现有代码和配置； 修改多个文件； 运行测试或启动服务； 根据终端输出继续修复； 检查差异，确认没有误伤其他功能； 把结果整理成团队能看懂的说明。 传统聊天窗口通常只负责“给建议”。剩下的操作，要由人复制、粘贴、切换终端，再把结果传回给模型。真正消耗时间的，往往不是生成代码，而是让代码进入工作现场，并在失败后继续往下走。 Cindy 的价值，正在于把这段过程连接起来。她可以使用本机文件、终端、浏览器以及其他工具，在一个持续的任务上下文中完成多轮操作。这样，AI 不再只是代码旁边的提示框，而更像一个可以被交代任务的协作者。 ...

🤖 【具身智能日报】 2026-07-22 📌 酷哇科技亮相WAIC 2026，解密行业首个双层智能体世界模型 （来源：量子位 | 时间：2026-07-22） 机器人真正需要的世界模型，并不是单一物理世界模型，而是物理世界模型与人类社会世界模型的统一。 从技术实演、新品亮相到底层模型架构解密，深耕城市场景的酷哇科技正以世界模型为底座，推动城市具身智能从单体作业走向多智能体协同。 核心进展： 双层世界模型发布：酷哇发布 COOWAM 世界模型，首创"物理-社会"双层智能体世界模型架构，区别于传统单一物理世界模型，融入人类社会行为预测能力 机械臂全天候实演：展台现场由 COOWAM 驱动的机械臂全天候制作"夏日特调"——切西瓜榨汁、拧瓶盖、配比柠檬片和苏打水，全流程自主完成 全地形机器人 X0：68kg 重载能力 + 全地形自适应行走，可突破楼梯、斜坡、碎石等立体复杂空间，结合高度模块化设计，无缝适配市政环卫、末端配送、安防巡检等场景 万台部署路线图： 酷哇规划"从围墙外走向围墙内"路径，日冕+远图万台级具身智能部署计划官宣，2027年百台级，远的未来目标万台。 📌 百度文心助手任务Agent登顶PinchBench，超越Claude、GPT （来源：量子位 | 时间：2026-07-22） 在59个参评模型中，百度文心助手任务Agent以94%以上得分登顶国际权威PinchBench榜单，领先 Claude Opus 4.8-fast（93.5%）、GPT-5.6-luna（88.7%）等。 PinchBench 由 Kilo AI 推出，考的是"智能体能不能把整件事做完并交付可验证结果"，区别于传统大模型基准考的"模型知不知道"。当前版本包含23个真实工作场景、147项任务，覆盖数据分析、代码开发、办公自动化等七大类别。 核心启示：Agent时代，框架工程能力的重要性正在超过单纯的模型参数比拼。 💡 影响分析 短期：双层世界模型填补了具身智能"物理+社会"统一认知的空白，机械臂实演证明技术已接近可部署状态 中期：万台部署计划意味着具身智能从Demo走向规模化落地，工业场景先行验证是关键节点 不确定性：多智能体协同的安全性、复杂地形适应性仍有待长周期验证 #具身智能 #机器人 #WAIC2026 #世界模型

今日概览 本期技术日报精选 5 条优质内容，涵盖 AI Agent 元控制台、浏览器自动化、支付基础设施和身份认证等领域。查重后新增 5 条，推送成功。 AI Agent 元控制台与新范式 1. omnigent - 所有 AI Agent 的元控制台 推荐指数：8/10 omnigent 是一个 AI Agent 的元控制台（meta-harness），为 Claude Code、Codex、Pi 以及自写 Agent 提供统一抽象层。它支持跨 Agent 动态切换或组合、无需重写代码即可添加策略控制和沙箱隔离，并支持多设备实时协作同一会话。 对于需要同时运行多个 AI Agent 或需要精细化管控 AI 行为的企业开发者来说，这是一个值得关注的基础设施级项目。随着 Agent 市场快速扩张，能够统一管理多种 Agent 的平台将变得越来越重要。 🔗 https://github.com/omnigent-ai/omnigent 2. ponytail - 让 AI Agent 像最懒的高级工程师一样思考 推荐指数：8/10 ponytail 是一个全新的 AI Agent 框架设计理念：让 AI 像最懒的高级工程师一样思考——最好的代码是不写的代码。这个项目用极简的方式重新定义 AI 编程助手的行为模式，强调不写多余代码才是最高效的编程哲学。 项目刚发布就获得 22.8K stars，增长极为迅猛。这代表了 AI 编程工具从「能写」到「懂省」的趋势转变：不是让 AI 无限地写代码，而是让 AI 学会判断什么时候不该写。 🔗 https://github.com/DietrichGebert/ponytail ...

本期导览 本期技术日报从 GitHub 周榜中筛选出 3 条值得关注的 AI 相关项目，涉及 RAG 优化、跨平台 Agent 数据采集、AI 输出质量控制三个方向。 头条速递 🏷️ [AI] headroom 🔥 推荐指数: 8/10 📌 RAG 输出压缩工具，60-95% token 节省，质量不变 🔗 https://github.com/chopratejas/headroom 💡 在 LLM 应用中，token 成本往往是最大的开销之一。headroom 通过智能压缩技术，将工具输出、日志、文件和 RAG 分块数据在传给 LLM 前进行压缩，实测可节省 60-95% 的 token 用量，同时保持回答质量不变。项目支持 Library、Proxy 和 MCP Server 三种部署模式，GitHub 一周增长 10,653 颗星，是 AI 基础设施层面值得关注的技术方案。对于 token 成本敏感的项目（如长文本 RAG、频繁调用 API 的 Agent），headroom 有直接的降本价值。 🏷️ [AI] Agent-Reach 🔥 推荐指数: 7/10 📌 AI Agent 跨平台数据采集，Twitter/Reddit/GitHub/Bilibili/小红书全覆盖，零 API 费用 🔗 https://github.com/Panniantong/Agent-Reach 💡 Agent-Reach 解决了 AI Agent 在实际场景中"看不见互联网"的核心痛点——一个 CLI 工具即可覆盖 Twitter、Reddit、GitHub、Bilibili、小红书等主流平台的数据读取和搜索，完全不需要支付任何 API 费用。GitHub 29,806 颗星，一周增长 5,468 颗。对于需要跨平台信息聚合的 AI Agent 项目，或者研究社交媒体舆情、竞品分析等场景，这是一个零成本的强力方案。 ...

从 OpenClaw 切到 Hermes：一篇面向 AI Agent 日常使用的 Hermes 实战教程 最近我把自己的 AI Agent 工作流从 OpenClaw 切到了 Hermes。切换之后最大的感受是：OpenClaw 更像一个 Agent 控制台，而 Hermes 更像一个会越用越顺手的个人自动化运行时。 如果你之前用 OpenClaw 的重点是多渠道接入、Agent 编排、团队协作，那么 Hermes 一开始可能会显得更"轻"。但如果你的核心需求是：每天让 Agent 帮你处理重复任务、跑命令、查资料、写代码、做总结、记住上下文、沉淀技能，那么 Hermes 的体验会更贴近个人长期使用。 Hermes Agent 是 Nous Research 推出的自改进型 AI Agent，官方文档把它描述为带有内置学习循环的 Agent：它可以从经验中创建 skills，在使用过程中改进 skills，并通过记忆和历史会话搜索来形成跨会话上下文。(Hermes Agent) 一、Hermes 适合什么人？ 我建议把 Hermes 理解成一个「个人 AI 工具执行器」，而不是单纯聊天机器人。 它比较适合这些场景： 个人开发者日常工作流 比如读项目、改代码、写脚本、查日志、生成 PR 描述、总结报错原因。 长期重复任务自动化 比如每天生成日报、定时检查服务、每周整理资料、定期做项目审计。Hermes 官方 GitHub 页面提到它支持内置 cron scheduler，可以把定时任务投递到不同平台。(GitHub) ...

受够了 OpenClaw 的失忆，我本周爱上了 Hermes Agent 大多数人以为 Hermes 只是一个 AI 聊天框架。但它实际上是一个可长期运行、多角色协作、多入口接入的 Agent Runtime，已经非常接近真正意义上的 AI Operating System。 Hermes Agent 在不到三个月内突破 14 万 GitHub Star，并根据 OpenRouter 的数据成为目前全球使用量最大的 Agent。在折腾了 2 个月，受够了 OpenClaw 的失忆后，我尝试用业界火热的 Hermes Agent，效果居然出奇的好，因此写下这篇安利文章。 关键词：#openclaw #Hermes 能力标签：多Agent协作 · 长期记忆隔离 · 子代理并行 · 多用户隔离 · 任务编排 · Agent Runtime 为什么这么火？三个根本原因 1. 解决了 Agent 领域最痛的问题——失忆 Hermes 要解决的正是这个问题，不是用 prompt 技巧，而是在架构层面内置了一个闭环学习机制——运行时间越长，它就越了解你。 2. 自我进化的技能系统 Hermes 有四个核心差异化能力，其中最突出的是"自进化技能"——它会自己编写并优化 skill 文档。每当 Hermes 解决一个困难问题，它就会写下一份可复用的 skill 文档，之后永远不会忘记这个解法。这些 skill 可搜索、可共享，并兼容 agentskills.io 开放标准。 ...

Superpowers 14 个 Skills 全解读：AI 编程纪律框架的完整拆解 最核心的价值不是某个单独 skill，而是这条链路： 需求澄清 → 设计确认 → 计划拆解 → 隔离开发 → TDD → review → 验证 → 收尾 这条链路正好针对 AI coding 最常见的失败模式：过早实现、缺少测试、猜测修复、跳过验证、过早宣布成功。 注意：要经常更新 skills 的代码版本和自己结合实际使用，将自己的经验和要求增加到 skills，以便更好的编程和业务准确性，最好是将自身业务的要求单独作为 skills 引入到编程工具里。 Superpowers 是一个给 AI 编程 Agent 的完整软件开发方法论，由一组可组合 skills 和初始指令组成。它的基本工作流是：先澄清需求、写设计、写实施计划、TDD 实现、代码审查、验证、最后合并/PR/清理。 该不该装？三层判断 层面 判断 技术层面 不必须。没有它，AI coding agent 也能写代码。 工程质量层面 对复杂项目，强烈建议。它强制 TDD、审查、验证，能减少"AI 自信但没验证"的问题。 Superpowers 自身规则层面 一旦安装并启用，它的 using-superpowers 明确要求：只要有 1% 可能适用，就必须先调用相关 skill；README 也说这些是 mandatory workflows, not suggestions。 我的建议：重项目安装，轻任务选择性使用；团队协作/生产代码建议默认启用；纯探索、一次性原型可以不用或显式绕开。 1. using-superpowers — 入口规则 这个 skill 不是某个开发动作，而是**"调度所有 skills 的总开关"**。它要求 agent 在任何任务开始前先判断是否有相关 skill；只要有一点可能适用，就要先调用 skill，而不是凭经验直接干。它还规定了优先级：用户明确指令最高，Superpowers skills 其次，默认系统行为最低。 ...