@coefu 6

@coefu #13
我这里的涌现指的是让 agent 可以主动的去承接任务，从而让工作流不必定义，由能够干对应活的 agent 一直动起来去处理自己关心的事情，文章内的 harness 与我做的事情并不冲突，单个 agent 越强大，在总线上的处理的事情就越好，其他 agent 发布的事实也能更好的协作，这两件事本质上并不冲突。

文章内提到的多 agent 遇到的困难，按照一元论来说必然是走 workflow 才是最优解，因为他们是要解决一个特定任务的最优执行路径。但是我是在探究一个持续运转的 Agent 集群，怎么在没有人预先设计工作流的情况下，让活儿自己被认领、被做完。

附上我本地跑的 MVP 系统，我发出一个需求事实（做一个简单的 CRUD 页面），各 AGENT 一直主动的处理 bus 上的东西最终做到的效果，
https://i.imgur.com/p139Ecg.jpeg

https://i.imgur.com/PF4KJOq.png

他们不互相指挥，只处理总线上的东西

https://i.imgur.com/pmQWeok.jpeg

在这个 MVP 系统中，各个 agent 仅有 SOUL.md 描述自己的职责，没有向 harness 角度持续优化自身，强化之后就可以做更复杂的系统了

代码感兴趣的话可以参考一下: https://github.com/YangKGcsdms/antlegion-platform 不过加了 UI 角色之后，我对于 MVP 场景的事实领域还没有做治理，导致几个 AGENT 跑起来会经常发呆

现有的 Multi-Agent 系统，本质上还是在用分布式的壳包一个中心化的大脑。🥱

@coefu 还有就是你发的文章内几百 Agent 集体摸鱼的案例，恰恰能说明命令驱动编排器在规模化时会集体崩塌，最后只能用状态机强行隔离。我的方案是从协调原语上就避免这个问题，而不是等崩了再打补丁

@coefu 额 你这个文章不是在说怎么让单个 agent 做更好的事么，其实 Harness 补偿的是模型执行力的不足，但工作流本身的结构依然是中心化设计出来的。如果是流程边界清晰、责任链确定的任务，Harness 的结构化设计是合理的。如果涉及任务边界模糊、Agent 动态加入退出、下一步依赖上一步结果的场景，我的这个涌现逻辑更合适 https://i.imgur.com/4sNwQQK.jpeg 另外我也不是想当然的 yy ，我是实打实的在做落地

@maolon https://i.imgur.com/W5ofLDQ.png 昨天基于事实协议做的一个五六十 agent 的居民小镇

@extrem 不是这样的，llm 可以当做函数被调用，被组装，agent 需要升维看待了，当前 agent 已经到了要建立语义层的地步

@charlie21 通过前置的过滤器与 SOUL.md 就可以实现

@sillydaddy 那倒不用，同一事实的多个 agent 靠争抢与排它锁就行，主要是按照事实过滤而不是看 agent 谁强谁弱

@bxb100 https://i.imgur.com/NIvxivj.png 我用 OPUS 读了一遍 Think in java 抽了一堆写书的 skills ，跑了一天跑出来的这个，不过感觉确实多此一举了

@yamedie #31 wx eXlra2dnMjUyNQ==

@dassh #24 wx eXlra2dnMjUyNQ==

@tftNExtLife #30 @yamedie @dassh

eXlra2dnMjUyNQ==

@dassh 有价值么，有价值的话私你

@yamedie 有价值么，有价值的话私你

@zisen 跟朋友聊了一下，确实是多此一举了，private 了已经

@baoziyucha 可以的哥，随缘的，不点也没事

@tina2998 让 ai 速读一遍就行了