… - 我构建了一个系统，其中上下文（+当前状态+目标）被正确地结构化，编码代理只获得他们真正需要的信息，而不会获得更多信息。你不会让产品经理开发你的后端，而我只让后端开发人员做他们应该做的事情，而不会做其他事情。如果一个代理崩溃（或配额限制达到），代理可以继续从其他代理停止的地方开始。- 代理之间在某种程度上是“互相竞争”的吗？架构师试图进行设计，而CAB试图拒绝。- 细粒度控制。我不会称“管理者”为“一个确定性的状态机，它调用概率函数”，但某种程度上它确实如此？管理者有明确的任务（比如“如果文件在01_design目录下 —> 调用架构师”）。这是其中一个旧代码库中在实现一个功能后的代理日志示例：https://pastebin.com/7ySJL5Rg
源讨论Claude Code的新隐藏功能：群体原帖 335 条评论 · 导入时统计这是讽刺吗？
完整原文把你的经验，加入这段讨论。
你用了什么OpenCode原语来实现这个？我非常希望有一个“资深”的Opus代理来制定计划，一个“初级”的Sonnet来执行工作，还有一个资深的Opus审核员来检查它是否与计划一致。
完整原文> [...]编码代理只获得他们实际需要的信息，而不会多任何多余的信息 基于这个概念进行推断，我得出了一个可能有点偏激的观点，我还没来得及写博客：代理式AI将使微服务的流行度重新上升。这主要是由于上下文长度对代理性能的负面影响。
完整原文当你说到你有一个经理、Scrum主管、架构师，所有这些似乎共享同一段记忆时，我感到很困惑。这些“员工”是否知道自己是谁？如果是的话，他们的身份是根据什么定义的？是提示吗？还是其他什么东西？或者只是我太笨了，无法理解，正在逆流而上。不管怎样，这听起来太棒了！
完整原文这一切不就是手动实现的提示路由，以及在某种程度上，专家混合模型吗？ 这些工具和服务本来就应该能对特定的提示做出最好的处理。你所做的工作基本上证明了它们做不到，同时还投入了更多的资金。 用户还要手动管理LLM的上下文多久才能充分利用这些工具？为什么在这一技术出现五年后，这仍然是一个问题？
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。