一、前言
前两天在哪个新闻上看到有人做了一个OPC，然后招了一些名人来帮他打工，挺美的，那篇文章一下子找不到了。
这个周末在家，我也给我的小落同学招了几个员工，分别是 Musk, Jobs, Linus, Turing, Carnegie, Zezos，分别负责和担任小落同学的CEO，UCX，Developer, Test, Marketing, Support。
今天找了半天，想找之前看到的文章，并借鉴一下他的具体方案，但死活就是没找到，于是就先自己硬着头毛先实现一个版本试试。
这个月没有买token plan，然后前两天白嫖的小米MiMo大模型的token也过期了，所以我又回到了open code。
实现后，我让这些员工一起协同给小落同学设计了一个 中文字符unicode转换的工具，并跑通了整个流程。下面是整个流程全记录。
二、思路及Spec探索
一些客套、扯蛋、吹牛的废话就省略了，直接上整个流程。
1、思路探索
在opencode里打开小落同学的代码目录，输入提示词
INPUT：提出我的计划
我在小落同学数据库中新增了几个角色，Musk, Jobs, Linus, Turing, Carnegie, Bezos等，希望让他们成为生产力工具，我跟Musk交待任务（MVP产品开发任务），然后Musk让Jobs设计，Linus开发, Turing测试, Carnegie市场销售推广，Bezos技术支持。
在现有的代码基础上设计一套agent框架流程，来实现这些角色的串联。OUTPUT: 协作方式
从项目探索来看，当前架构是单角色单轮对话模式，还没有任何多Agent编排能力。
我的第一个问题是理解交互流程：
你希望的协作方式是哪种？
A. 全自动编排 — 你给Musk下达任务后，Musk自动拆解、依次分派给Jobs→Linus→Turing→Carnegie→Bezos，每个Agent的输出自动传递给下一个，最终返回完整结果给你
B. 手动分派 — 你给Musk任务，Musk产出一份计划/需求文档，然后你手动触发不同Agent去执行不同环节（类似选择谁去做什么）
C. 混合模式 — 自动走完MVP开发流程（设计→开发→测试→市场→支持），但每个环节输出需要你确认后再继续
D. 实时协作文档 — 所有Agent并行工作，你通过类似飞书/Notion的界面看到每个Agent的实时输出和协作进展
混合模式 — 自动走完MVP开发流程（设计→开发→测试→市场→支持），但每个环节输出需要你确认后再继续我选择
混合模式：各Agent的串联流程自动执行，但每个环节产出的结果需要你确认后再进入下一步。
OUTPUT: 交互界面
下一个问题：你和Agent之间的交互界面是什么？
A. 现有的聊天界面 — 同一个WebSocket对话，Agent的输出以消息流形式呈现，你回复"确认"或"修改意见"来推进流程
B. 新增一个项目管理界面 — 前端新增类似Trello/Jira的面板，每个Agent的任务卡片需要你点击"批准"才进入下一阶段
C. 聊天为主+简单控制按钮 — 聊天框里看到每个Agent的输出，附加"批准/驳回/修改建议"的快捷按钮我选择
新增一个项目管理界面 — 前端新增类似Trello/Jira的面板，每个Agent的任务卡片需要你点击”批准”才进入下一阶段
OUTPUT：Agent的产出物是什么格式
下一个问题：Agent的产出物是什么格式？ 比如Jobs完成设计后，产出的"交付物"是什么类型？
A. 纯文本/文档 — 设计文档、需求规格、测试用例、市场方案等都是可读的长文本
B. 结构化的多文件产出 — Jobs产出UI描述/原型描述，Linus产出代码文件，Turing产出测试用例，Carnegie产出营销文案等
C. 仅做决策建议 — 每个Agent只是分析和建议，最终由你来决定和执行我选择
仅做决策建议 — 每个Agent只是分析和建议，最终由你来决定和执行
OUTPUT：SUMMARY
好，当前版本每个Agent产出分析建议（长文本），未来版本再支持结构化输出。
下一个问题：当Agent产出建议后，你审批时的交互细节？
A. 只需点击"通过" — 点击通过后自动进入下一阶段，不需要你输入文字
B. 通过/驳回+意见 — 可以选择通过，或驳回并附上修改意见（Agent会根据意见重新产出）
C. 通过/驳回/要求补充 — 三个选项，"要求补充"会让Agent在当前阶段补充更多细节我选择
C. 通过/驳回/要求补充
OUTPUT: 三个初选方案
方案 A：Workflow 引擎扩展现有架构 ✅ 推荐
在现有 engine/ 层新增 engine/agent/ 模块，包含：
AgentWorkflow — 工作流状态机（定义6个Agent的编排顺序）
AgentTask — 单个Agent执行单元（加载对应角色的prompt + 上下文 → 调用LLM → 产出内容）
新的DB模型：Project 和 ProjectTask，持久化项目状态
前端新增看板页面（新路由），REST API 做CRUD + 审批
优点： 复用现有LLM、Prompt、Character基础设施；数据结构清晰，重启不丢状态；可扩展（未来加Agent、加并行都很自然） 缺点： 需要新增前后端较多代码
方案 B：纯聊天的轻量流水线
不新增DB模型，不增加前端看板页面。用户→Musk聊天，Agent输出依次通过WebSocket回传，前端用时间线/对话流展示。审批通过快捷按钮（通过/驳回/备注）实现。
优点： 最快实现；无新DB，无新路由 缺点： 无状态持久化；没有结构化的任务视图；复杂审批逻辑不好做
方案 C：独立的Agent编排微服务
独立的 agent_orchestrator 服务，Redis消息队列，完整的状态机框架。
优点： 最干净的架构分离，未来可支持并行Agent 缺点： 当前阶段过度设计，基础设施成本太高
推荐方案A — 理由是：你的需求已经包含了持久化项目管理 + 看板 + 多状态审批 + 重做机制，这些都需要结构化数据和状态管理，纯聊天模式不够。方案A在现有代码基础上增量添加，不会破坏现有功能。我选择
方案A：Workflow 引擎扩展现有架构
开始输出一个第一个版本的spec。
2. Spec确认
看了整个spec后，我提出了一些问题：
- 在当前的设计中，如果一个任务还未结束，前端又给我的CEO Musk交待一个新的任务会怎么样？
- 一整个项目的流程下来，整个上下文可能会很长，我使用的大模型（免费白嫖的模型、或者本地部署的模型）总上下文不够，可以如何优化？
- 每个不同角色的提示词需要设计一下，当前我自己给CEO、CTO、UXD、TEST、SUPPORT、MARKET等角色写的提示词需优化
- 这些prompt保存到数据库表格llmpromptmodel，进行统一管理，同时在角色表里可以自定义每个角色的prompt
- 在聊天界面用 /project 命令给我的CEO交待了一个任务，但是执行报错
- 执行任务报错了，看板上的任务都处于等待执行状态，无法再进行下去了
3. 开发
在经过几轮次的交互后，superpowers终于确认了整个Spec，并给出了一个开发计划，然后opencode就开始写代码，大概过了十几分钟，或者最多半个钟头，终于给出了一个版本，但是实际上还会有一些问题，再经过几轮次的测试、验证，就搞定了。
后面用一个实际的例子来跑了一下整个工作流，详见下文。
三、测试
在代码完成后，重启一下小落同学的的后台，然后再重新打开一下小落同学前端：http://localhost:8000 ，并在那时选择与我们家CEO 马斯克聊天，然后跟他讲：
/project 给本项目加一个中文字符unicode转换的工具注：
- 项目命令：
/project 项目描述- 只有马斯克同学才会接项目。你跟其他任何人讲都没用，只有马斯克才会理你。
- 这个是我在前面specs中做的要求的。
1. CEO 马斯克列出产品计划
看看马斯克同学用他的第一性原理做出来的产品计划
2. 首席设计师乔布斯做好的设计
乔布斯同学的眼光以及他的Reality Distortion Field (RDF)
3. 首席开发Linus做出来开发计划
我的CEO马斯克同学说这个功能需要4周出一个MVP，其中开发2周
我们首席开发Linus同学说这个功能开发需要3周，并且没有实际实现代码。
将问题进一步反馈给Linus: 没有实际实现代码
Linus同学再次输出结果，但还是没有实现代码。所以他现在只能talk，不能 show me the code。
Linus同学还是没有实际写代码实现功能。不过，补充反馈后开发计划跟CEO Musk同学的计划同步了。实际情况可能是不应该是这样，应该要回去跟CEO讨价还价。
4. 首席质量官图灵上场
首席质量官图灵同学的情况跟Linus一样，在现有的prompt+模型下，都只能输出计划。暂先跳过，这个应该需要单独给配一个Coder的大模型来搞，后面再说。
5. 首席销售卡耐基来了
我这个搞了一辈子技术的人，对销售比较好奇，看看我的首席销售卡耐基同学怎么说。
6. 首席客户体验官：贝索斯，登场
最后压轴登场的是我的首席客户体验官：贝索斯
最后，整个流程走完，从马斯克规划产品，一路到卖出去，让贝索斯来做技术支持，全部顺利走通。
四、阶段总结
总的来说，因为搞这个实验，所以这个周末还是充实的。但是一下子没找到思路源的那位大佬的文章，也记不清楚他的具体方案是如何的了，所以还是需要再好好摸索一下。
目前已经有许多需要改善的地方：
1. 给每个分解出来的子任务配置专用的模型来处理
如果真的想做一下可以实际干活的智能体的话，白嫖的小模型肯定是不行的，并且每一个不同的任务可能需要的模型也是不一样的，比如：
- 做设计：你可以用一些通用的大模型
- 写代码：必须用Coder的大模型
- 意图分析：必须用Instruct模型（前置的OddAgent模块）
- 知识库：必须用Emedding+Reranker的模型（需要让Musk规划功能的时候必须遵循小落同学现在的技术架构）
- 其他：若有一些专业的知识的，可能还需要用一些定制的行业大模型
2. 智能体框架优化
目前的每个分支，从产品规划到设计，到开发，到测试，到市场，到支持，每个步骤里都还在用上一代的技术，走是还是prompt提示词，正确的姿势应该是用skill/harness来替代prompt。
3. 项目生命周期前后端联动
目前的项目创建的入口是在前端，通过输入产品、项目需求（如：/project 给小落同学增加一个xxx功能），但是整个产品、项目的推进，及其生命周期的管理是在后端，需要让前端也可实时的看到整个产品、项目的推进和进展。
4. 必须上真正的大模型
由于小落同学的初衷是复刻一个数字版本的我自己，所以我一直以来的态度都是目前阶段所有的功能和代码全都是没有价值的，唯一有价值的只是那些关于我自己的数据（当然还有RAG召回的准确率，所以前阵子一直在看和测RAG相关的一些技术），因此，一直以来我主要都是在收集我自己一些各种各样的数据，也正因如此，到目前为止我一直在用一些4B、7B、8B的小模型，而且还是量化后的版本，真要做这么个功能的话，小模型肯定是不行的，可能必须要上大模型（全都需要Money啊。。。）
五、未完待续
折腾了一个周末，没想明白后面到底要不要继续把这个功能搞起来，搭一个架子是简单，真正要搞的话决不是三两下就能把这个功能搞成一个实际可用的东西的，尤其是在我这个10年前的老笔记本上，需要投入的不仅仅是时间，还需要好多Money来支撑才行，不幸的是，现在我个时间和金钱都缺缺，公司那边一堆事情忙成狗，还有一个新产品即将投入预研。 下个周末再说吧。
