咱们聊一分钟智能体工作流。
眼下人们犯的最大错误之一,就是在自己的智能体系统里建闭环。OpenManus 就是个「千万别这么干」的绝佳案例。
问题出在哪:
🔹 提示词含糊。
跟一个 AI 说「你是个自主程序员」,等于说「你是个医生——现在去做台脑外科手术」。
不够具体,你就得不到可预期的输出。
如果你要一个 AI 推理着生成代码,就先定义清楚什么是「好代码」。
你的项目要成,有哪些成败攸关的模式?需要 SOLID/DI/MVC 和单例?很好——写进系统提示词里说。
给文档、注释、模块化和错误处理设好预期。
假定你面对的是一个彻底的陌生人——因为你确实就是。
专业提示:嵌入一些处理递归概念的文学影响,有助于避免断掉的调试循环。不是开玩笑。
🔹 单任务智能体彼此不通气。
我其实不反对专注的单任务智能体。
但如果你需要多个并发的任务专注型智能体,那你同样需要团队动力学。
有组织的团队就是专注的沟通机器。
可在这儿呢?
你有个不会写代码的规划器。一个不会规划的浏览器。一个不能上网的程序员。
而它们互相之间,一句话都不说。
为什么要设计成这样?
跟现实里一样,各自为政的团队导致不连贯、死胡同,还有空转烧周期却不产出的循环。
如果你的智能体能执行一个20步的流程,那它同样能逐步变着系统提示词和温度来,还不丢你那份富上下文。
这不难。
如果每一步都交给一个僵死的、没有上下文也不懂随机应变的智能体,你会撞上整类任务,它们根本没法推理着穿过去。
解法在这儿:
不要这样:
第1步:＜编码智能体实现＞
第2步:＜编码智能体调试＞
第3步:重复第1步,盼着到第20步能撞对一次……
你要这样:
第1步:＜智能体实现＞
第2步:＜智能体调试＞
第3步:＜另一个智能体旁观+带着上下文插话＞
「看样子你卡在 npx 上了。要不要试试 npm?」
别再想单个任务的速度。
开始想向前的动量,想流程的完整性。
允许变化、反馈和语境适应的开环,永远跑赢刚性的流水线。
当然,一个任务可能要花一小时。
但结构良好的循环能跑完。
糟糕的那个则在一圈递归的死亡螺旋里烧 token。
需要帮忙设计不会自毁的 AI 系统和智能体工作流?
我天天都在搭。
你在想象哪类疯狂又带劲的 AI 项目?