从 opencode 到 Agent-Do：Workshop MVP 的瘦身重构
opencode 提供了强大的 Agent 基础，但把一个大项目深度植入 Workshop 会引入额外复杂度。生成、流式输出、会话、工具调用、文件写入、运行预览，每一层都有自己的状态和假设。
当目标是快速做出可用 MVP 时，正确方向不一定是继续集成大系统，而是重新收窄边界。
MVP 边界
Agent-Do 的目标可以更明确：接收需求，生成项目，运行验证，返回结果。它不需要一开始覆盖 opencode 的完整交互体验，也不需要继承所有内部结构。
边界越窄，调试越直接。
真实问题
重构阶段暴露出的关键问题包括：
- 容器内 workspace 挂载到错误宿主路径。
- Docker CLI 在容器中不可用或路径不稳定。
- 生成结果为空时缺少兜底。
- 启动脚本和预览服务之间的约定不够清晰。
这些问题都说明：Agent 系统的稳定性不只来自模型能力，也来自运行环境 contract。
复盘
从 opencode 到 Agent-Do 的瘦身，不是推翻前面的探索，而是把探索过的能力压缩成最小可控链路。复杂系统适合提供参考，MVP 则必须保留最短路径。
工程上真正重要的问题是：当前阶段需要的是平台能力，还是可验证闭环。Workshop 的第一阶段答案是后者。
知识补全：MVP 不是少做，而是少承担不确定性
MVP 经常被误解成“功能少一点”。更准确地说，MVP 是把当前阶段不需要承担的不确定性移出去。
对 Workshop 来说，完整 opencode 体系包含会话、工具、终端、编辑器、模型适配、状态流和复杂包结构。如果第一阶段目标只是“用户输入需求后得到可运行项目”，那么这些能力大多不是主路径。
Agent-Do 的瘦身价值在于把系统主路径压成：
prompt -> generate -> write workspace -> run check -> return result
只要这条路径稳定，后续再加流式 UI、云部署、历史任务和复杂工具都更容易。
重构判断清单
遇到大型开源项目改造时，可以用这组问题判断是否该瘦身：
- 我需要的是完整产品，还是其中一个能力。
- 当前 bug 是业务逻辑问题，还是原项目运行时假设不匹配。
- 新系统是否能用更少的状态表达同一条主路径。
- 删除模块后是否会丢掉关键能力。
- 未来扩展是否还能接回被删除的能力。
如果答案指向“主路径可以更短”，重构就不是倒退，而是把工程风险重新收束。
实际拆分步骤
把大系统瘦身成 MVP 时，可以按三个动作做。
第一，画出用户真正经过的主路径。Workshop 的主路径是输入需求、生成项目、验证运行、返回预览或文件。
第二，把不在主路径上的能力降级为后续插件。例如复杂会话管理、完整 IDE 体验、长期记忆、多模型工具链，都可以先不进入核心。
第三，为核心路径补 contract。生成器必须知道输出目录，运行器必须知道启动脚本，前端必须知道任务状态格式，容器必须知道 workspace 挂载点。
这样做的结果是：系统虽然小，但每一层边界更硬。后续加功能时，是在稳定主路径旁边扩展，而不是继续把不确定性塞进核心。