WorkBuddy 一周实测:个人工作和小团队,到底能用它做什么?

WorkBuddy 一周实测:个人工作和小团队,到底能用它做什么? 实测环境:macOS,WorkBuddy 5.2.7,连续使用一周。 信息复核:2026 年 9 月 9 日。官方更新日志显示,桌面端最新版本为 5.5.3。本文中的耗时、资源占用和识别效果,都是我在 5.2.7 上的单次或少量测试记录,不代表官方承诺。版本与价格以 WorkBuddy 更新日志 和 腾讯云计费说明 为准。 我把 WorkBuddy 装到 Mac 上时,没打算拿它“颠覆工作”。我只是受够了来回搬东西:飞书里翻聊天记录,复制到文档,再把表格数据塞进 PPT,还要单独写一封邮件。WorkBuddy 和普通聊天工具最不一样的地方,不是它更会说,而是它能在我授权后读文件、跑工具、生成文档,再把结果交到下一个应用里。官方把它叫“全场景职场 AI 智能体桌面工作台”,我用了一周后的说法更土:它像一个坐在我电脑里的执行型实习生。任务说清楚,它能省掉不少机械操作;任务说含糊,它也会一本正经地跑偏。【关键词:#WorkBuddy #AI智能体 #个人效率 #小团队协作】 我最先跑通的是周报。 周一早上,我把一周的会议纪要、零散待办和几份项目文档放进同一个工作区,要求它按“已完成、风险、下周计划”整理,不准碰两个敏感项目。那次三分钟出了初稿,我又花五分钟改人名和优先级。省下来的不是写字时间,而是从十几个窗口里捞信息的烦躁。可我第一次下指令时只写了“帮我整理本周工作”,它把私人备忘也扫进去了。这个翻车让我定下一条规矩:先圈目录,再说任务;先写禁区,再点运行。后来我把个人任务收成五类,效果稳定了不少: 长文档压缩。 我拿一份 80 页产品白皮书,让它输出 300 字摘要、关键参数表和三条待确认问题。普通文本版约 90 秒就完成,够我拿去开内部会。换成扫描 PDF 后,表格和页脚开始串行。原稿里我写过“识别率掉到 60%”,这个数字只来自那一份样本,不该当成产品能力。我的处理办法很简单:先做 OCR,再让它摘要;关键参数回到原页核一遍。 PPT 起稿。 我先给客户类型、演示时长、听众最关心的问题,再让它出 12 页结构和视觉草稿。那次从空白页到可讨论版本,比我自己从零搭快很多。没有客户画像时,它默认按中小企业写,整套方案方向都偏了。AI 能补页面,补不了我没说出口的业务背景。 批量整理邮件。 我让它给 200 封未读邮件做“客户、同事、订阅、待删除”分类,并把涉及付款、合同、交付日期的邮件单独列出。五分钟左右分完,少数客户群发信被扔进订阅类。我没有让它自动删除,也没有让它直接回信。发邮件、删邮件这类动作,我都保留临门一脚的人工确认。 代码和表格杂活。 一份约 200 行的 Python 脚本,它两分钟找出两个真问题,也塞给我五条偏风格的建议。我只修能复现的错误。把客户资料从一个表搬到另一个表时,它能做字段映射,但“公司简称”和“客户名称”猜错过一次。批量写入前先拿五行试跑,比事后清两百行脏数据轻松得多。 公众号初稿。 我给主题、读者、真实案例和禁用词,让它先搭草稿。十分钟能有一版,但“过渡词加升华收尾”的味道还是会冒出来。现在我只让它整理材料和找结构,真正的判断、情绪和具体经历自己写。能交付文件,不等于能替我表达。 小团队场景比个人场景更考验边界。 我和两个同事把它当“团队实习生”用了三天。最顺的一次,是把三份 Word 会议纪要拆成待办,再写进协作表格。我们事先约定四个字段:负责人、截止日期、动作、优先级;没有负责人就标“待认领”,不让它猜。十二分钟后表格能直接发群。最糟的一次,是让它“自行选择合适工具”,它连续调了一串 Skill,任务做完了,积分也掉得肉疼。官方技能文档建议只启用当前任务需要的 Skill,我很认同。Skill 本质上是脚本和工作流,会在授权范围内读写文件、调用第三方服务;部分 Skill 还会把输入发给第三方。别把“装得多”当成“能力强”,闲置 Skill 该关就关。连接器也一样。官方连接器文档列出了邮箱、腾讯文档、腾讯会议、TAPD 等接入场景,飞书、钉钉等也有单独的助理接入指引,但每个连接器能读什么、能写什么,要看实际授权。我的做法是把团队任务拆成下面这条链: ...

2026-09-09 · 1 min · 125 words · FunkyGod

Trae、WorkBuddy 和 Agent:搞懂这三者,非程序员也能玩转 AI

Trae、WorkBuddy 和 Agent:搞懂这三者,非程序员也能玩转 AI 我电脑里同时装着 Trae 和 WorkBuddy。一个长得像 VS Code,打开就是一整屏代码;一个长得像微信,打开就是个对话框。同一个"AI 助手"的名号,干的活差着十万八千里。关键词:#workbuddy #trae #agent 而 Agent 是另一回事儿。它不是一个产品,是个概念。你可以把它想成"汽车"这个品类——Trae 和 WorkBuddy 都是车,但一辆是越野车,一辆是家用 SUV。 先说最重要的一句话:Agent 是一个概念,Trae 和 WorkBuddy 是两个产品。 我用个不太恰当但好懂的比喻:Agent 相当于"汽车"这个品类,而 Trae 是"越野车"、WorkBuddy 是"家用 SUV"。都是车,但干不同的活儿。 那 Agent 到底是什么? Agent 直译过来是"智能体"。它和咱们平时聊的 ChatGPT、豆包、文心一言这类聊天机器人(Chatbot)不一样。 聊天机器人,你问一句它答一句,本质是"问答"。 而 Agent 是"干活"。你说"帮我订明天北京到上海的高铁,上午十点左右,二等座",它会自己拆任务、自己查车次、自己下单、自己填地址。整个过程你不用一步一步指挥。 一个能真正干活的 Agent,需要三样东西: 大脑:大模型(比如 DeepSeek、豆包、混元),负责理解和决策; 记忆:能记住你之前说过啥、做过啥,不会聊两句就忘; 工具:能调浏览器、调表格、调你电脑上的软件,这是干活的"手脚"。 缺任何一样,它就只能"陪聊",干不了正事。 那 Trae 和 WorkBuddy 又是啥? 懂了 Agent 是"汽车品类"之后,Trae 和 WorkBuddy 就好理解了——它们都是 Agent 的具体实现,但定位完全不同。 Trae 是字节跳动在 2025 年初推出的 AI 原生 IDE。所谓 IDE,就是程序员写代码用的"大本营"。它底层基于 VS Code,打开就能用,内置了 Claude、GPT、豆包等多个大模型,主打"中文体验最好、对开发者最友好"。 ...

2026-09-08 · 2 min · 269 words · FunkyGod

我现在的「AI 工作台」:codex + Cindy + openclaw + kilo

我现在的「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 的。

2026-09-07 · 1 min · 65 words · FunkyGod

我如何把 Pi Agent 接进 Office/WPS 办公流程:从安装到 Excel 长任务

20260904|我如何把 Pi Agent 接进 Office/WPS 办公流程:从安装到 Excel 长任务 我最初接触 Pi Agent 时,也只是把它当成一个写代码的终端工具。真正让我觉得它适合办公,是我把一项复杂任务拆开之后发现:办公里最耗时间的部分,往往不是写一段话,而是把邮件、会议记录、网页、表格和历史文件里的信息拼起来,再按一套不够明确的规则反复处理,最后还要证明结果没有改错。 关键词:#Office #WPS #Pi 对经常使用 Office 或 WPS 的人,我更愿意把 Pi 理解成一个坐在旁边的办公助理:它不替我换掉 Word、Excel、PowerPoint 或 WPS,而是帮我在多个文件之间找信息、整理内容、生成草稿、执行低风险的重复动作。它可以在本地的“办公工作区”——也就是我专门放这项工作的文件夹——里读取资料、调用工具、保存一次连续的工作记录,并把中间结果留下来。但它不是“按一下就全自动”的魔法,也不是替我做业务判断的数字员工。 本文先把安装对象和桌面适配讲清楚,再用 Excel 月报这个长任务说明我如何让它参与办公,以及我为什么坚持把验证和最终提交留给自己。先把名字理顺:大家口中的“pi-agent”,对普通使用者来说通常指的是会安装出 pi 命令的 @earendil-works/pi-coding-agent;@earendil-works/pi-agent-core 是底层运行时库,不是新手第一步要装的客户端。下面的命令和版本判断以我在 2026 年 9 月 4 日查到的官方快速开始文档、官方仓库和相关 package 资料为准。 下面看到的黑色窗口命令,主要只在安装和整理文件时使用;装好以后,我仍然可以继续用熟悉的 Excel、Word、PPT 或 WPS 图形界面办公。对不熟悉命令行的朋友,我建议把它理解成“给办公助理下达准备工作指令”,先照着复制执行即可。 先准备运行环境:当前官方仓库的 package.json声明 Node.js >=22.19.0。Node.js 是 Pi 运行所依赖的基础环境,我会先用 node --version 检查版本;低于这个版本就先升级 Node.js。旧文章里如果还写着 @mariozechner/pi-coding-agent,以当前官方文档使用的 @earendil-works/pi-coding-agent 为准。然后安装并验证: npm install -g --ignore-scripts @earendil-works/pi-coding-agent pi --version macOS 或 Linux 也可以使用官方安装脚本 curl -fsSL https://pi.dev/install.sh | sh;Windows 则建议先安装 Git for Windows,因为 Pi 默认通过 Git Bash 执行 Bash 命令,官方也支持在设置里指定 shellPath。安装成功后,进入我准备给它工作的目录再启动: ...

2026-09-04 · 3 min · 564 words · FunkyGod

OpenCode 和 KiloCode 的主要区别是什么?为什么我会选择 KiloCode?

20260903 OpenCode 和 KiloCode 的主要区别是什么?为什么我会选择 KiloCode? 最近 OpenCode 和 KiloCode 经常被放在一起讨论:一个让我在终端里专注完成任务,一个把多个 Agent、隔离工作区和代码审查组织进 IDE。很多朋友真正想问的其实不是“谁更强”,而是“我现在的工作方式,应该把哪一个放在手边”。这篇文章记录我最近一次切换工具的原因,也把我认为最影响选择的差异讲清楚。蓝色高亮表示工具事实,绿色高亮表示我的判断,红色高亮表示容易踩的坑,黄色高亮表示可以直接尝试的做法。文中的产品信息按 2026 年 9 月 3 日查阅到的官方文档整理,后续可能随版本变化。 先说我的结论:如果你主要在终端里工作,喜欢自己控制会话、目录和模型,OpenCode 依然是一把很顺手的工具;如果你经常同时推进多个任务,希望在 VS Code 或 JetBrains 里集中看状态、diff 和工作区,KiloCode 更贴合我的习惯。更准确地说,Kilo CLI 是 OpenCode 的 fork;Kilo 的 IDE 插件和 Agent Manager 则是 Kilo 另行组织的产品层。所以它们不是两个完全无关的竞品,也不是同一个产品换了两个皮肤。 我为什么又换了一次?上一篇文章里,我写过自己怎样把 OpenCode 接进日常开发,那些经验现在仍然有效:终端里可以跑命令,配合 LSP(语言服务协议)理解代码,也可以通过 MCP(模型上下文协议)接入外部工具,项目规则则写进 AGENTS.md。后来我的任务从“一个人在终端里重构 Go 服务”,变成了同时推进重构、补测试、写文档、审 PR 和修 bug,还要在 VS Code 与 JetBrains 之间来回切换。OpenCode 的多 session 能力并不弱,只是我需要自己安排目录、创建 git worktree(并行分支工作区),再盯住每个会话的进度。KiloCode 的 Agent Manager 把这部分协调工作做成了看板:每个 Agent 可以在独立 worktree 里运行,我只需要负责拆任务和合并结果。 ...

2026-09-03 · 1 min · 213 words · FunkyGod

OpenCode,别急着上手,分享我的自用经验

OpenCode,别急着上手,分享我的自用经验 最近一段时间 OpenCode 的话题度很高,公众号和推上每隔几天就有人晒"一天配置、终身起飞"。我也凑过几次热闹,但说实话,真正把它当成日常开发工具并接入 AI 用,是在吃了几次亏、调过几次规则之后才稳定下来的。这一篇不是官方文档的搬运,也不是"hello world 教程",我会先讲我为什么把 OpenCode 作为日常开发工具并接入 AI 用,列 8 条最容易踩的注意事项——尤其是"装上第一天别急着写规则"。如果你正在评估 OpenCode、或者已经装上却不知道从哪一步开始,这篇可能比"快速上手"那一份更值得花十分钟读完。蓝色高亮表示工具或事实,绿色高亮表示我的使用判断,红色高亮表示容易踩的坑,黄色高亮表示可以直接抄走的最小可用集。、 先把"为什么用"想清楚:换模型不被绑架、过程可观察、本地运行——这三条都满足了,再谈下一步。 从最小可用集开始:一份简短 AGENTS.md + 一个稳定 Provider + 一个默认 build 角色 + 启用的 LSP。够用就好。 复杂任务先 plan 再 build:跨文件的改动,先看 diff 再下手,能避免一整轮返工。 规则要可验证、规则要文件化:机器能判的才叫规则,读不懂的只是愿望。 审查用只读 agent:把"看"和"改"分开,是让 AI 报告客观的前提。 接入 MCP 时按"只读 → 受限可写 → 状态变更"分步放权:每一步都先想清楚"最危险的事是什么"。 不要让关键检查静默失败:可见、可追溯、有人负责,三条缺一不可。 把 AI 当草稿作者,把自己当责任编辑:最终交付的责任,不能下放给工具。 一、把 OpenCode 放进工作流之前,我给自己提过三个问题:它能不能让我换模型不被绑架?它能不能把每一步操作摊在我眼前?它能不能在我自己的机器上跑,而不是把代码交给一个远端托管? OpenCode 在这三个问题上都给出了让我愿意留下来的答案,这也是我后来把它接入 AI 用作日常开发工具的真正原因。我把这三个答案按顺序写下来,因为它们不只是在"功能上"成立,更是OpenCode 与同类工具最明显的差异点: 开源、可审计、不绑定单一供应商:OpenCode 的客户端代码是公开的,关键行为可以在源码里核对;Provider(也就是模型供应商)走的是开放协议,我可以在同一个配置里同时挂上 OpenAI、Anthropic、本地 Ollama、自建代理,换模型不需要重写工作流,更不需要换一份订阅。对我来说这意味着两件事:第一,今天贵/限流的模型,明天可以被另一个模型接住;第二,今天数据合规的顾虑,明天可以通过本地模型或者自建网关绕过。这条不是装饰,它直接决定了我愿不愿意把生产代码交给它。 把"工具调用 + 文件编辑 + 命令执行"收进一个 TUI:比起网页聊天窗口,OpenCode 的好处是上下文连续。一次会话里,它可以直接读写我的文件、跑我的命令、调用我的 LSP,并把每一步的结果作为下一步输入。传统聊天窗口要靠我在不同窗口之间复制粘贴,OpenCode 把这些步骤变成了同一个会话里的多轮工具调用。对我而言这比"模型写得多聪明"更重要:我能在同一个界面里看见它读了什么、改了什么、跑过哪些命令、回滚时还能回到哪一步。信任不是靠宣传词建立的,是靠"可观察"建立的。 配置即文档,规则可以在 review 里被讨论:OpenCode 的绝大部分约定都放在纯文本文件里:项目根的 AGENTS.md 写规则,commands/*.md 写命令模板,agents/*.md 写角色,skills/*.md 写沉淀下来的做事方法。最常见的错误是把 AGENTS.md 当成无所不包的"价值观大全",其实它的价值恰恰相反——把"我想要的工作方式"显式写下来,让工具按文件读,而不是每次新会话都让我重新解释一遍。规则在哪一步生效、谁负责什么,可以被同事直接读到,也可以在 review 里被讨论。这就是我把 OpenCode 当成"开发工具并接入 AI 用"的核心原因——AI 第一次成为工作流的一部分,而不是一个聊天侧栏。 二、装上 OpenCode 之后,先别急着让它"做项目"。我会先定一个最小可用集,把"模型 + 规则 + 角色 + 编辑器反馈"四件事按顺序配齐,再开始干正事。顺序不能乱,因为规则没写好之前,模型越强越容易跑偏。下面这 8 条技巧,前 4 条是"装好就能用"的最小集,后 4 条是"日常真正省时间"的核心姿势,全部按顺序展开,每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写,而不是单独列一节,这样读起来不会割裂。 ...

2026-08-30 · 3 min · 455 words · FunkyGod

心动公司开源的 Cindy:一个值得交代第一件任务的 AI Agent

心动公司开源的 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-08-20 · 2 min · 217 words · FunkyGod

从 OpenClaw 切到 Hermes:一篇面向 AI Agent 日常使用的 Hermes 实战教程

从 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) ...

2026-06-06 · 5 min · 1026 words · FunkyGod

受够了 OpenClaw 的失忆,我本周爱上了 Hermes Agent

受够了 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 开放标准。 ...

2026-05-25 · 2 min · 369 words · FunkyGod

数字生产实践Codex:AI 编程助手进化到桌面办公智能体

数字生产实践Codex:AI 编程助手进化到桌面办公智能体 AI 编程工具正在从代码生成器,进化为能够操作环境、验证结果、持续协作的软件开发智能体。 在过去,很多人对 AI 编程工具的理解还停留在"帮我补全代码""生成一段函数""解释一段报错"。但 OpenAI 最新版 Codex 的能力已经不止于此。 根据 OpenAI 官方对新版 Codex 的介绍,Codex 正在从一个单纯的代码助手,升级为贯穿软件开发生命周期的智能协作伙伴。它不仅能写代码、理解代码库、处理 PR 评审,还开始具备两类更接近真实开发者工作方式的能力: Computer Use,也就是操作系统级控制能力; 内置浏览器,也就是在 Codex 应用中直接打开、观察和操作网页的能力。 这两项能力的出现,意味着 Codex 不再只是"回答怎么写代码",而是开始进入真实开发环境,帮助开发者完成更完整的任务链路。 一、Codex 正在从代码助手变成开发智能体 传统 AI 编程工具的核心能力是生成代码。用户提出需求,AI 给出代码片段,开发者再自己复制、运行、调试和验证。 而新版 Codex 的方向更接近 开发智能体。 所谓开发智能体,不只是会生成代码,而是能够围绕一个开发目标,主动完成多个连续动作: 读取项目文件; 理解代码结构; 修改代码; 运行终端命令; 打开页面; 复现问题; 检查界面; 验证修复结果; 根据反馈继续调整。 也就是说,Codex 的价值正在从"生成代码"扩展为"完成开发任务"。 这背后最关键的变化,就是它开始具备 操作电脑 和 观察网页 的能力。 二、什么是 Computer Use? Computer Use 可以理解为一种让 AI 像人一样使用电脑界面的技术。 它不是简单调用 API,也不是只在编辑器里生成文本,而是让模型通过屏幕画面理解当前环境,并通过鼠标、键盘等方式执行操作。 它的基本能力包括: 看屏幕:识别当前界面中的按钮、输入框、菜单、弹窗和错误提示; 理解任务:根据用户目标判断下一步应该做什么; 执行操作:点击、输入、滚动、切换窗口、打开应用; 观察反馈:根据界面变化判断任务是否完成; 持续迭代:如果没有完成,就继续调整下一步操作。 可以用一句话概括: ...

2026-05-21 · 3 min · 617 words · FunkyGod