# 把智能留给原生 Harness，把连续性做进系统

## 我的架构判断：少替模型做决定，多保证它能把事情做到底

我做这项工作的起点，是反复遇到一种落差：助手说完成了，用户却没拿到能用的东西。可能是按钮不能点，也可能是答案已经生成却在收尾时丢失，或下一轮换了执行者，原工程和人的修改都没有带过去。

这让我从“怎样再造一个更聪明的 Agent”，转向另一个问题：**怎样让已有的优秀执行系统保留本领，并围绕同一件作品持续工作？** 我关注的不只是调用模型，而是输入、工具、执行、交接、采用和用户使用之间，哪一段真正接上了。

## 1. 模型、Agent、Harness、工作室与运行底座，不能混为一谈

在我的设计里，模型提供推理与生成能力；Agent 是围绕某个目标工作的实例；Harness 是承载它的执行系统，包含循环、工具、权限、上下文、会话和恢复。“子 Agent”描述委派关系，不代表能力较弱，它也可以由完整 Harness 承载。

工作室则可能拥有自己的专业流程、多个执行者和原生状态。向它委托一个明确范围的任务，不等于把它拆成普通聊天接口，更不应该由两套系统重复指挥同一份工作。

Meyo 这层运行底座要统一的是目标、工程、授权、委托关系、成果版本和事实记录，而不是各家的全部内部实现。原生系统保管自己的会话与执行历史；平台保留准确关联，让需要帮助的成员能找到工具、拿到材料、收到真实回执。像接通不同车间：统一工件和交接单，不要求每个车间换成同一台机器。

因此，工具后端不应冒充答题成员；登记、安装、可执行、完成任务也必须分别呈现。

## 2. 从自研 auto 到开放协作：留下能力，收回“总大脑”

技术路径经历了固定流程、自研 auto 自主使用工具，再到连接成熟 Harness。auto 留下了搜索、文件处理、脚本执行、来源核对与连续工作的积累；但让同一个内核兼任执行者、规划者和最终裁判，维护面会不断扩大。

历史复盘记录过一个反例：模型已经写出答案，后续检查和收尾却把它变成了空结果。外部监督也未稳定兑现预期收益。这些是历史实验观察，不足以否定所有评审方法，却足以让我放弃“再叠一层判断，就一定更可靠”的直觉。

我的取舍是 **context not control：安全边界可以硬，质量策略应该回到任务和执行者。** 权限、取消、进程回收、资源与版本冲突必须由系统约束；设计方案、研究深度、是否求助、怎样改善作品，则应由成员根据本次目标与证据决定。

这不是取消验证。检查发现要带着原材料、具体失败和可操作的工具入口回到作者，让它继续处理，而不是只在最后发一个总分。用户要求不能被偷偷降低，外部材料也不能借“上下文”获得额外权限。

## 3. 工具接通的证明，不是返回成功，而是原作品真的改变

工具有目录、有名称，甚至返回“完成”，都不等于它执行了所需动作。我把能力借用分成三种：能独立完成的直接调用；依赖原生状态的委托原 Harness 或工作室；确有接口或复用需要时，再研究有许可的源码。读过源码、借用成功、学会方法，是不同结果。

对源码理解，我的判据也不是生成一张全仓地图，而是能解释一个具体机制：由谁触发、哪项配置启用、状态归谁、失败和取消怎样传递、结果如何回到用户。索引负责带路，源码和运行证据负责证明；用最小反例检验解释，足够支持当前修改就停，不为“彻底理解”无限扫描。

**2026 年 10 月 14 日的个人运行验收，提供了一条具体证据链。** 操作员选择原生 Codex 执行报告任务，用户指定 OhMyGame 工作室参与专门复核。初版报告的归因被指出有问题后，原成员需要读回审阅意见并修改原文件。

途中出现了两个真实断点：原生 shell 无法完成工作室的进程身份检查；工具参数描述过于空泛，成员反复提交空参数。修法不是删除检查或关闭沙箱，而是把获准的宿主动作交给受管 MCP 调用，并明确参数传递方式，保留原校验。

记录显示，修后成员真实传入文件参数、接续工作室审阅、核对意见，并修改原 Markdown 与 HTML。切到固定版本的常驻服务后，另一条阅读反馈仍沿同一原生会话更新原报告；新版 Markdown 经浏览器下载，与成员原文件逐字节一致。

这一单证明了委托、意见采用、原会话续作和文件取回。它没有证明自动选出了最佳协作者，也不是新游戏制作或多人云服务的验收。真正有价值的变化是：帮助不再停在另一份回复里，而是回到了用户正在使用的作品。

## 4. 连续工作要保住工程，不只是保住聊天记录

项目、对话、一次执行、原生会话和成果版本各有作用。相同会话编号不能单独证明续作成功；下一位执行者还得拿到实际工程、当前版本、依赖、人工修改和未完成事项。

交接回执还要拆开：已保存、已送达、已消费、已应用，不是一件事。断线或超时后先查原执行，不能盲目重派；旧执行晚到的结果只保留为观察，不覆盖新负责人的版本。换负责人转移的是执行责任，不是作品所有权。

我倾向于完整保存获准保留的事实，运行时只发送相关索引和可读回的原文引用。压缩的是每次传输，不是删掉证据。同家继续与跨家接手也要分开：前者可能恢复原生会话，后者可能是在新会话里接过原工程，不能称为跨格式无损迁移。

并行开发同样不是“多开几个窗口”：成员从共同基线进入独立写入空间，由明确的负责人读取真实差异、处理冲突并集成。单个分支失败要保留，不能用另一个分支的成功覆盖它。

版本采用则是另一项决定。历史 3D 作品记录中，接力成功后画面反而退化；引入更新资产的尝试也出现实体不显示。**更新不等于更好，执行成功不等于应该采用。** 我的设计是把稳定成果和候选修改分开，验证后按授权采用，保留可恢复的旧版。代码回退不能被夸大成付款、外发消息或数据库副作用都能撤销。

## 5. 用真实旅程和全成本，回答协作到底值不值

历史材料中的聚合、投票和路由实验，并没有共同支持“人越多越强”。一次调度候选虽然提前启动后继任务，总耗时仍更长；另一次候选更早结束，但对照没有完成同样的工作。这类结果能帮助定位机制，不能直接包装成普遍提速。

我的基线是先用足合适单家的原生能力，再看补位是否减少缺口。简单文字任务可以直接回答；专业交付要能打开、编辑或执行；复杂项目才按实际需要展开协作。比较时必须保留相同输入、工程和资源约束，算上失败、重试、协调与人工救场，不能把对手的能力剪掉后宣布获胜。

质量也必须回到用途。历史太阳系任务曾把交互作品续成静态图片，画面变了，却丢了用户要的体验。后续回原工程保留交互再补内容，才是沿原目标改善。网站能加载、文件存在、测试通过，都不能独自回答作品是否好用；参照应帮助作者理解具体差距，而不是成为固定闯关清单。

成本账同样如此：我关心的是**每件被接受且实际使用的合格成果总成本**，包括模型、工具、计算与存储、失败和人工，以及按真实复用次数摊销的准备维护费用。首次有用内容、首次可用作品和再次继续的时间分别观察；低 token 单价不等于低交付成本。

跨系统委托不能重置总预算；保存、索引、脱敏、转换与兼容维护也有成本。费用缺测应保留未知，而不是记成零。

## 6. 社区与私有云：让作品成为下一次行动的起点

从内容生产走向作品协作，我保留下来的产品判断是：让社区看起来热闹，不等于别人真的获得了能力。更值得验证的方向，是让人从可体验的作品发现用途，再决定独立使用、加入贡献或提出自己的目标。

社区是发现共同工作与成果的地方，画布是处理同一项目的工作视图。关系应来自真实行动：谁提供材料，谁修改，谁验证，哪些贡献被采用。复制一份自己的版本不等于加入原项目；调用过某个 AI，也不自动成为有效贡献。公开作品、共享方法和使用统计需要分别授权。

作品入口也应把“源码参考”“外部体验”“平台内可运行”分开，标清来源版本、所需账号和实际访问范围。有链接不等于已托管，地址能打开也不等于获得修改权限；授权发布应绑定一份冻结快照，后续私有修改不能悄悄改变公开内容。

私有云方案因此要分清五种对象：来源作品、固定的可运行版本、用户私有项目、应用运行实例、Harness 修改会话。可以共享经过验证的只读基础，但用户数据、凭据和写入不能混在公共演示里；持久的是用户资产，计算可以按需启动和休眠。普通使用已有作品，不必每次重新调用 Agent 生成代码。

这是后续产品方向，不是已经交付任意仓库托管的声明。先从一件有真实使用人的成熟作品验证“试玩—自己的版本—有效修改—回来继续”，比铺满模板和成员名单更有意义。会话历史适配工具可以帮助交接，但不能替代工程、素材、数据备份和运行隔离。

## 7. 我愿意用什么证明下一步

目前可明确展示的是上述个人实例中的报告交付与续改；旧作品演进和协作记录提供局部观察。多用户私有云、跨任务方法复用、同质量降本和持续用户收益，仍需要各自的证据。

我希望下一步留下的，不是更多“已接入”徽标，而是一条别人能追问到底的链：**原始需求是什么，哪里失败，为什么这样改，原作品怎样变化，用户是否采用，还有什么没解决。** 方法只有在另一条真实任务中再次被采用、产生净改善，才值得称为积累；若协作不划算，就保留单家。