关键在于需求如何对齐。真人做开发任务，都需要在过程中反复对齐需求，agent 只负责开发，需求对齐最终还是要传导到你这里的，不是加一个 agent 负责验收就能解决的事。你可以让 agent 一次性做得很多，做错了会增加成本，浪费很多 token 和时间。

Agent 和现实世界的交互就是命令行和对话框，最多看看静态资料，非常缺少隐式需求探索的能力。而且目前长期记忆仍然是一个问题。
这些都加剧了这个问题。

眼睛啊，至少弄个电子墨水屏吧

有没有可能 openai 加了路由，如果判定是低需求问题，或者是黑号了，就会偷偷路由到低级模型上

@sampeng 做自己懂的东西是的，毕竟自己知道应该做成什么样。 现在有了 agent 之后，可以用来做更大的，超出自己知识和精力范围之外的东西了。 超出知识范围还好，可以学，超出精力范围就实在没有办法了，只能靠 agent 了。 所以模型智力很重要嘛，但这么多的人测智力的大多都是跟风图一乐而已，自己的那半亩地都种不好的

开发三步骤嘛，提需求，实现，判定正确性。 判定很难的，没这能力就只好依赖 ai 了…… 而且现在很多人用来做整个产品，或多或少都有这方面问题的

什么是中低级，都没有定义。crud 算吗，前端后端算吗，中型业务系统算吗，算法算吗

每次看到 duo 都会幻视 dio

@siriusliangcn 还好，把 csdn 屏蔽之后还行😂优先用英文搜索

其实以前也没用，Google 一下也有了……

😂以后当面聊天都要 gpt 润色一下

说实话，日志真得 ai 看，比写代码还强

怎么你们都是得到的鸡汤吗？ prompt 不是要求给知识么😂……给我的真的就是知识

我认为你最有必要知道的是：你现在正在碰到的，本质上不是“Agent 编排问题”，而是控制论里的“必要多样性定律（ Law of Requisite Variety ）”。 这条定律是 W. Ross Ashby 在控制论中提出的，粗略说就是：一个控制器想可靠地控制一个复杂系统，它自身能够区分和处理的状态复杂度，至少要覆盖被控制系统中那些真正重要的变化。 换成人话就是：系统有 100 种会出事的方式，你的检查机制只能识别其中 20 种，那么无论 workflow 写得多漂亮，剩下 80 种迟早会穿过去。人类非常喜欢用流程图解决认知不足，仿佛多画几个框就能获得知识，遗憾的是宇宙没签这个合同。