tftNExtLife

@coefu 6

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

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

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




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



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

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

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

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

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

@maolon 昨天基于事实协议做的一个五六十 agent 的居民小镇

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

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

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