多 Agent 把一局网页游戏跑起来并不难。个人练习里，Demo 能进、能打、能结束。难的是把它接进团队：组织认知要转，成本要能评估，边界要去探。

游戏研发里做 Agentic，常见情况是：

• 能跑通 — Harness 能调工具，Demo 能玩，下一步不知道干什么
• 接不进 — 个人练习停在自己这，组织不知道这东西算不算数、要花多少、能碰到哪
• 验不了 — 对错靠聊天里模型自评，没有「这一次过了」
• 用不起 — 工作台在，日常还是开新聊天，loop 转不起来

我们的实践：Harness 叙事的是接入更多插件，Loop 是为目标不断做减法。先用 Loop Harness 让策划自己把需求拆开、做出来、自动验收，但策划的注意力不该放在质量上，研发不能甩手。再在研发侧把 Build Loop 做成 Build Control：人先在 loop 里拍板，再把人往外抽；一开始目标切错，后面迭代越快越不值得信。工作台基于 DeepSeek Harness。本次分享讲 Demo 之后，Loop 怎么接进团队。

演讲提纲

1. 背景：Demo 能跑，接不进团队

• 个人练习：网页游戏 Demo 里的多 Agent 协作
• 协作不是瓶颈；后面会在多模态、引擎适配的多个阶段撞墙
• Harness 叙事的是接入更多插件，Loop 是为目标不断做减法
• 真正难的是接进团队：认知转型、评估成本、探索边界
• 痛点：Loop 接进团队时，认知、成本、边界怎么评估

2. 实践：Loop Harness 让策划自己开发需求

• 帮策划做三件事：需求拆解、实现、自动化验收——需求能自己切开、能做出一版、过线不靠口头说
• 策划的注意力不应放在质量。质量是研发的职责，Loop Harness 不是把测试、过线、背锅转交给策划
• 所以研发不能甩手：策划在 loop 里出需求、出实现；研发守验收、守质量、守「这次能不能过」
• Loop Harness 做减法：只留给策划「这个需求要什么」，不把插件、模型、质量面板堆到策划面前
• 痛点：如何把拆解、实现、自动验收交给策划，又不把质量注意力压过去、不让研发甩手

3. 实践：研发实践中的 Loop Engineering

• Build Loop 就是 Build Control。Human in the loop 到 Human out of the loop 不是切换开关，是信任建设：人先对每一次构建拍板，Agent 跑；人少碰，是因为验收还在，不是因为人不管了
• 人还在的时候，拍板权在人；人往外抽，权要留在 loop 的验收上，不能留在模型自评里
• 一开始 loop 的目标错了（Spec 切偏、过线切错），后续迭代交不出信任：跑得越勤，错得越稳，人更不敢退出
• 先把目标按住，再谈人退出。目标不对就停、就改 Spec，不要用更多迭代去「跑出信心」
• 痛点：人怎么从 in the loop 退到 out of the loop，信任落在哪；目标一开始切错，为什么多跑几次也交不出信任

4. 实践：工作台，让 loop 有人愿意接着转

• 基于 DeepSeek Harness：上一个需求长出来的能力，下一个还能用；工作台可克隆
• 日历/待办：现在该验证哪一次构建
• 后台 tmux：构建是长任务，人离开 loop 还在转
• Git 任务列表：下一步从当前 Spec 来，不从聊天贴
• 授人以渔：愿意把日常控制放到这条 Build Loop 上，而不是每次重开 Demo
• 痛点：工作台如何避免变成第二个聊天窗（待办垃圾场、tmux 过多、Git 太吵）

实践痛点

认知门槛相对较高，很多人处在Chat、Vibe Coding的状态

前沿亮点

• 结合 DeepSeek Harness 定制化提效
• 需求级工作台，而不是又一个聊天 Agent：人改 Spec 和红节点，不改 prompt；验收是 Graph 节点变绿，失败可单点重跑。这是从 Harness 跨到 Loop 的接口，不是口号
• Spec 按 DDD 划界、编译成可并行 DAG：区别于手拖画布。多个需求已按此落地，拆成数十个可见节点并行；边上约束的是上游产物（接口/模型/Spec 片段），上游没齐下游不能绿
• DeepSeek Harness 的插件化 + 三个可复用演示：日历/待办、持久 tmux、Git 远端任务列表同等展开，每块都带真坑（垃圾场待办、会话过载、远端噪声）。证明 Loop 要接到「下一步从哪来、人看哪一路、能力如何复用到下一需求」
• 授人以渔有技术载体：成员在 Multica 里用 Harness 克隆领域 Agent，组织资产越用越厚，而不是平台组再发明一套通用机器人

听众收益

• 了解前沿 Loop Engineering 实践
• 拿到 Demo 之后的下一跳：从「Harness 能跑」到「需求进、节点绿出」的工作台接口，以及 Loop 三层怎么拆着设计，避免停在技术叙事
• 一套可借鉴的切分与关系维护方法：需求级 SDD 先 DDD 划界，再编译 DAG；用上游产物约束并行，处理「太粗不能重跑 / 太细会扯皮」
• 三个可复用的工作台插件方向及避坑：认知卸载（待办不要变成垃圾场）、后台持久会话（tmux 要解决看哪一路）、远端任务驱动（Git 列表必须过滤）。帮助团队少把空转换到下一个容器里