Diodeme

@chjqpmain

明白了，感谢老哥把你的使用方式和看法讲得这么具体。

我觉得我们这里更多还是使用场景和习惯不同，你说的这种主 harnes 统一调度的方式也完全成立，我们则更偏向把流程状态、验收和失败回环交给工程化的 runtime 管理。

这里其实也是目前行业内主流的两种不同做法，两种方式各有适用场景，等我把前面说的复杂任务案例真正跑出来，再用结果说明我们这套方式到底有没有价值。

感谢交流🙏

@chjqpmain 感谢老哥分享你的感受，其实我们项目目前的亮点是工作流，我在文章的一些问题这一段里，有专门说过我们和 codex 客户端等工具的区别。而之所以我说我们是他们的上游，是因为我们认为一个 agent 目前可以看成是一个 harness ，而我们可以工作流的方式编排不同的 agent(harness)，以在每个节点去使用最佳的 harness 完成任务，而不是同一套 harness 使用不同的上下文(这就是对应老哥说的只用 codex 去完成任务)，然后这里工作流还有一个好处就是，每个节点是独立的，流程又是系统控制的，所以在长程任务上表现更好。
所以可编排可自动分发的工作流是我们目前和其他类似产品最大的差异点。
至于文章有车轱辘话，这可能是因为我目前还是想着先把我们所有功能推出来给大家看，导致重点反而不突出了，谢谢老哥提醒。
后面我会用我们的工具尝试一次性去解决一个非常复杂的任务，比如用 java 重写 pi agent ，并改造成 client relay host 架构，用这种例子，来说明我们项目的价值，而不是再继续强推了。因为我这种宣传，确实大多数人和老哥一样，都不会试用。🥲

不知道是不是他们产品决策上把这个排序能力给去掉了，现在我都是手动拖拽会话排序，或者看活动视图

@zuokanyunqishi

如果你说的是行文风格比较像 AI ，那这个我以后会再注意下我的遣词造句；如果你说的是这篇是 AI 写的，这篇帖子我很早就写好了，也发布在 L 站了，那边是禁止 AI 写作的，除了问题这一章中与 orca 的区别那一段是我昨天临时新加的，有用 AI 润色过，其他部分都是我手敲的。

文风这种东西确实比较主观，我不准备在这上面做更多争论了。还是更欢迎大家一起讨论产品和技术，产品上有哪些地方做得不合理也欢迎直接喷。

@PowerDi 是有些相像，但我们目前除了常见的 acp 客户端的 ADE 式体验外，还有一个重点是通过由系统控制运行的工作流（人工定制或者 AI 自分发）去解决 agent 处理大任务时难审计难把控质量的问题。
所以我们的场景除了常见的对话式解决日常需求，还有一个重点就是针对大规模的、长程任务的处理，希望能真的做到人只需要确认需求和方案，后面的完全由 ai 去一把实现。

@hikarugo 另外我的主题列表隐藏已关闭，这个我之前都忘记还设置了这个，感谢大佬提醒并附上了我上篇帖子的链接。🙇‍

@androidCoder 大佬，我是纯手敲的，可以参考我上面的回复

@hikarugo 感谢大佬提醒，这些问题是我考虑不周了，起因是我是先在 L 站发的帖子： https://linux.do/t/topic/2740096/6 ，询问大家怎么激活送的 pro 会员，下面有朋友说没想到我们 star 数比较少也能过，所以我也想着趁这次机会宣传下我们的项目。这里可以看我的帖子，或者我的邮件截图： https://static.dion.blue/2026/08/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_17879085785851.png 。

大佬说得对，这次我确实是抱着蹭热点的想法来推广的，因为前面几次宣传效果都不是很好，用的人都不是很多，我本身技术人员出身，也是第一次推广宣传，所以还不是很清楚该怎么做最好，有一些操作可能看起来比较迷，还请大佬见谅。

另外这篇推文我原来也在想是否要放到发现创造里，但考虑里面涉及到一部分是分享开源活动申请的方法，所以最后还是放在程序员板块了。

最后是这篇文章是我纯手敲的，连 AI 润色都没有，因为有一次在 L 站发帖子用了 AI 润色，被拒了，后面为了避免麻烦，都是手敲的了，欢迎大佬用各种方式鉴定。至于看了两句没有欲望看下去，那确实是我自身文章功底薄弱，如果真是 AI 写的，应该比现在好得多。

后面再在 v 站发帖子，我会好好注意下这些问题的，感谢大佬的指教。👍

@yuiffy 嗯呐，可以试试的，参与别的开源项目也可以申请，不一定非要是自己维护一个