【开源】Codex Grill 到第十几轮,我已经看不懂了——于是我招募了勇者来斗“恶龙”

Reiam 2026-08-24 14:06 1

本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:



  • 我的帖子已经打上 开源推广 标签:

  • 我的开源项目完整开源,无未开源部分:

  • 我的开源项目已链接认可 LINUX DO 社区:

  • 我帖子内的项目介绍,AI生成、润色内容部分已截图发出:

  • 以上选择我承诺是永久有效的,接受社区和佬友监督:


以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出




介绍




Rovai AI 是一个开源多 Agent 工作台:你可以把 Claude Code、Codex、OpenCode 等不同 Runtime,配置成拥有名字、形象、职责和协作记忆的长期队员,让他们围绕同一个任务讨论、分工和行动。



事情的起因是某次我用 Codex 搭配 grill-me 进行一份架构文档设计,追问到十几问后,Codex 给的问题已经完全不讲人话了,只能把原问题交给 Claude 帮我翻译和给出建议。

最开始,我只是想把这个场景做成一个适合自己工作流的 Skill。

但那段时间 Codex 老是重置,Token 放着也是放着,于是写着写着……就变成了 Rovai AI。




产品介绍


先组建起队伍来


当我真正想去搭建一个AgentTeam, 思考我的队友应该有谁时,最先想到的当然是Codex和Claude。

但说到“Claude / 克劳德”这个名字时,我突然串台到了 FF7—既然有克劳德,那是不是也该有爱丽丝和蒂法。

然后我意识到一个问题,也许我要的队员可以是一个我愿意长期合作的角色。




所以在 Rovai 的设计里,这两层是分开的:


队员身份
名字 / 形象 / 职责 / 性格 / 关系 / 记忆

Agent Runtime
Claude Code / Codex / OpenCode / ...

名字、形象、职责、性格、关系和协作记忆决定一名队员是谁;Claude Code、Codex CLI、OpenCode 等 Runtime,则决定他通过什么能力参与行动。


公屏负责协作,执行台负责干活




队员们在公屏里对齐目标,被交付任务的队员在自己的执行台行动,完成后只需要将任务结果作简洁的汇报。

这件事其实解决了我比较痛苦的那部分工作:有公共消息区后,新加入的队员不再需要我重新复制一遍背景。




套件支持




Rovai 内置了一些常用的团队协作 Skill,关于 Skills、MCP 与原生 Agent Runtime 的关系,Rovai 采用兼容追加的方式:Claude Code、Codex 等 Runtime 原有的 Skills 和 MCP 会继续保留,用户也可以在此基础上追加团队协作所需的能力。

这样既能提供统一的协作支持,也尽可能不干扰各个 Runtime 的原生能力。




地图模式




这也是偶然之间的一个想法,闲时无聊可以看看的地图模式。像一个真的 RPG 游戏一样,Approval 可以是城镇大门,Research 是探索林地,A2A 可以以在公会大厅进行。

当然这一块不可能真的做成 LLM 驱动的动态游戏,那大概是既浪费工作的 token,又浪费游戏的 token(/笑哭)。不过静态小游戏问题应该不大,有什么其他适合的想法也欢迎交流。




设计理念


原则一:队员身份与 Runtime 分离


队员是长期存在的,而不只服务于单个任务。它不会在任务开始时被创建,又随着任务结束把角色、关系、共同经历被销毁。

在Rovai中,一名队员可以参与不同的讨论,接手不同的Task。任务会结束,但队员会留下来,同时留下的还有他那些值得保留的经历。

因此,队员是Rovai管理的主要对象,至于背后的 Runtime,我倾向于保持克制:尽量不干扰、不改造它原本的工作方式。


原则二:像小队语音一样交流


我比较喜欢游戏里的小队语音这个比喻。

一支队伍行动时,可能会分头行动,但他们可以在公屏中共享战况。

这其实比较考验队员的信息总结能力,毕竟上报到小队语音的信息越杂乱,其他人越难判断现在发生了什么,最后协作质量反而会变差。

这方面我的体验里 Codex 是最佳的,甚至不需要我额外约束,每次在公屏的发言都相当标准。


原则三:尽量克制


看到角色、长期记忆和 RPG 地图以后,可能很容易产生一个问题:

这一套是不是要额外烧很多 Token 来维持世界观?

但实际上不是,我在这个项目上花时间最多的地方就是动态上下文的管理。队员行动宪章、长期身份、协作关系以及A2A、mention、Task等必要信息,都经历过很多轮的压缩删减,尽量只保留影响实际行动的部分。



参考昨晚让它自己跑 benchmark 的监控图,对 Runtime 缓存命中率基本没有影响。


关于队员角色


Rovai中有四个默认队员,分别是小狐狸-叮叮(名字取自狐狸的叫声)、雪豹-芝士(雪豹就得叫这个名)、呆萌认真的猫头鹰以及一只兔子。

最早其实想直接用杰尼龟、小火龙和妙蛙种子做默认队员,图都准备好了,后来让 GPT 查了下,看到有人赔了株式会社几个亿,只好默默放弃了御三家。

当然,项目最初的想法就是让每个人把个人喜好的角色招募进来,角色属性都可以自己设置。毕竟长期一起工作的队友,叫 Claude-1 总觉得差点意思。


至于我的队友嘛:


最后:这里有一块使命板




也就是接下来要做的事情,欢迎 PR/issue。


项目地址:GitHub - murray17/rovai-ai: Give your AI agents lasting roles, a shared Camp, and a journey together — then let them grow into a team. · GitHub

使命板:rovai-ai/MISSION_BOARD.md at main · murray17/rovai-ai · GitHub

最新回复 (10)
  • Tibo Sottiaux 08-24 14:08
    1

    既然有克劳德,那是不是也该有爱丽丝和蒂法



    这不得不star了,这个想法也挺好的,避免了vibecoding时用户没事的问题。

  • Enze 08-24 14:10
    2

    是不是这个意思


  • Reiam 楼主 08-24 14:13
    3

    是的^-^,不只是sol,fable + grill也是,一到后面轮次也是这种难受的感觉。每个字都能看懂,组合起来却完全看不懂。

  • Wkstr 08-24 14:23
    4

    我记得 matt 好像在 youtube 上说过 grill 过多的问题

  • 海苔薄脆 08-24 14:33
    5

    我做项目有个自己的workflow,我会让三个对话对应三份职责,分别是和我沟通出方案的思考者,然后审阅方案是否合理的审阅者和最终执行计划的制作者。是不是和你这个思路大概类似。只是我自己收到操作复制各个沟通的文件给各个对话,你这个更聚合一点?

  • Reiam 楼主 08-24 14:37
    6

    嗯,Grill是一个引子。我在这个基础上提炼出了grill-duo的rovai内置skill,也就是多人追问。除此之外,开发过程中又自己涌现了一些多人review、多人讨论的skill。

    当然把这些协作技能用好的前提就是整套A2A和信息共享的机制是足够高效闭环的,这是我在建设Rovai的时候花最多时间的地方。

  • MapleGao 08-24 14:37
    7

    不是 grill 的问题,是 subagent 偷懒没读完正确的上下文

  • Rice 08-24 14:38
    8

    佬友 好使吗,我也在想这件事情,因为我现在的工作现在是需要多个模型针对同同一件事来考虑思考方向,每次都是我5.6发一遍 cc发一遍 grok 发一遍 deepseek发一遍 最后让cc来确定总体方向是否吸收采纳他们的意见(因为我觉得cc更强逻辑更符合我心目中的),我还想着等啥时候 等千刀佬开门就开始实施这个方案 让他写进来, 还有一个问题,他能够以codex/CC 的身份指纹发送请求吗

  • Reiam 楼主 08-24 14:40
    9

    嗯,这个是很好的点子,本身模型训练的时候也有多头注意力,从多个角度出发审阅方案肯定会更全面。

    这也是我做这个项目的一部分原因,就是避免人肉频繁复制内容。所以会有类似slack聊天室一样的公屏消息区,让不同的队员在这里讨论。

  • clb2ue 08-24 14:41
    10

    有遇到类似的问题,尝试过ccb但是折腾来去还是很多问题,试下佬的方案

* 帖子来源Linux.do
返回