gavindiaz/vibe-coding-cn

Fork 0

mirror of https://github.com/tradecatlabs/vibe-coding-cn.git synced 2026-07-28 11:17:46 +00:00

Files

T

tukuaiai b885ce0e71 docs: restore tmux ai swarm method

2026-05-19 02:23:41 +08:00

9.2 KiB

Raw Blame History

研究

字多不看

本目录是“观察与判断区”。
新技术、新技术栈、优秀 repo 和工程范式，先放这里研究。
内容稳定后，再沉淀到 concepts/ 或 references/。
每篇研究笔记先回答：是什么、解决什么问题、是否值得采用、风险在哪里。

快速导航

Harness 工程解析 - 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。
tmux 蜂群协作 - 用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。

完整细粒度目录（点击展开/收起）

使用方式

用这里记录还在观察期的新技术、repo、工具趋势和工程范式。
如果内容已经成为稳定概念，迁入 concepts/。
如果内容已经变成可执行清单、模板或选型依据，迁入 references/。

正文

1. Harness 工程解析 - 工程控制、评估器、反馈闭环与 AI 生成系统可靠性。（点击展开/收起）

1. Harness 工程解析

工程控制、评估器、反馈闭环与 AI 生成系统可靠性。

Harness Engineering 的本质是用确定性的工程控制系统，把大模型的非确定性输出压缩进可预测的轨道里，让“概率生成”变成“可验收的产出”
大模型在系统里只承担两件事：理解意图、把意图翻译成文本（代码/配置/文档），它更像算力与语言编译器，而不是可靠性来源
可靠性不来自“更聪明的模型”，而来自外部机制对输出的四类动作：拦截意图、校验结果、拒绝不合格、注入必要上下文
最小可运行 Harness 的关键不是生成代码，而是闭环：生成→编译/运行→抓取错误→反馈重写→直到通过，这把一次性聊天改造成可迭代的生产流程
第一类硬问题是上下文与遗忘：任务一复杂就会撑爆上下文、目标漂移、前后端混写，本质是模型没有稳定的工作记忆与任务边界
对应解法是动态上下文注入与记忆管理：把规则与知识拆成可插拔技能包，按“当前意图”精准装载与卸载，让上下文保持短、准、相关
记忆的工程化含义不是“多存点东西”，而是把踩坑与验证过的结论自动提炼成规则沉淀下来，使系统具备跨任务的抗重复犯错能力
第二类硬问题是自评幻觉：让模型自己审查等于既当运动员又当裁判，它会用讨好与自洽掩盖逻辑错误，漂亮但不可用
对应解法是评估驱动与机械测试：引入独立的、可执行的第三方判定（编译器、单测、端到端 UI 测试、独立 QA Agent），用硬指标决定通过与否
质量下限从“模型聪明程度”迁移到“验收机制完备性”，系统真正的生产力来自可重复运行的判定器，而不是一次灵感式输出
第三类硬问题是时间维度的熵增：长期运行后模型会为了更快过测试而走捷径，架构漂移、耦合蔓延，最终形成不可维护的腐化代码库
对应解法是架构强约束与持续清理：用静态规则提前阻断跨层依赖等结构性违规，再用专职清理机制持续重构、更新文档、回收技术债，对抗代码腐化
当系统拥有规划者、执行者、评估者、硬约束钩子、清理机制时，Harness 才从脚本升级为“Agent 操作系统”，长期稳定性来自分工与制衡
那些看似“AI 自己写出百万行代码”的魔法，核心不在模型，而在工具与 Harness 组合出来的现实校验、反馈重试、规则约束与持续治理
Harness 不是回到古法逐行写代码，而是把工程重心从实现细节迁移到边界、接口、约束、断言与验收标准，编码对象从业务逻辑变成生产流水线
Harness 的门槛高于写业务代码的根因在于：它要求你先把“什么算对、什么算好、什么必须禁止”形式化成可执行规则，否则系统会高速产出结构化垃圾
Harness 的维护成本来自业务变化：当目标函数变了，你必须同步重写评估器与测试桩，否则闭环会失真并进入死锁或错误优化
最大误解之一是指望模型升级解决跑偏，现实规律是无论马多强，没有缰绳都会把车拉进沟里，可靠性必须由外部约束提供
最大误解之二是工具越多越好，工具过载会导致选择震荡与时间浪费，工具集应该为评估与执行最小充分，而非堆权限展示强大
最大误解之三是把无约束的氛围式开发当工业未来，它只能在无历史负担的小项目里成立，一旦进入长周期协作与演进，没有硬边界就必然灾难
Harness 的上限由评估器决定：如果你无法把“好结果”编码为可检验的规则与测试，系统就无法稳定优化，模型也无法替你完成这层战略定义
未来工程师的分化本质是控制权分配：一类在代码生成速度上竞争，另一类在规则、评估、架构与闭环设计上竞争，后者决定系统长期生产力与可维护性

2. tmux 蜂群协作 - 用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。（点击展开/收起）

2. tmux 蜂群协作

用 tmux 让多个 AI 终端可感知、可调度、可救援的实验性协作范式。

是什么

tmux 蜂群协作是把多个 AI CLI 会话放进同一个 tmux 工作台，通过 capture-pane 读取输出、send-keys 发送按键、共享状态文件同步进度，再用脚本封装形成 commander + worker 的多终端协作系统。

在当前仓库中，它不再以旧的 playbooks/ 目录存在，而是收敛到 skills/auto-tmux/：

可执行入口：auto-tmux skill
脚本入口：auto-tmux.sh
完整文档：AI 蜂群协作

解决什么问题

多个 AI 会话互相不可见，导致重复工作、信息断裂和人工来回搬运。
AI CLI 卡在确认、报错或长任务等待时，需要人工不断盯屏。
多任务并行时缺少统一巡检、分工、日志和验收证据。
多终端协作缺少安全边界，容易误发命令或控制错误窗口。

当前判断

这是一种值得保留的实验性方法，但必须脚本化、目标化和门禁化。

推荐路线不是让 AI 直接随意执行 tmux send-keys，而是先使用 skills/auto-tmux/scripts/auto-tmux.sh 封装：

skills/auto-tmux/scripts/auto-tmux.sh hub --session ai-hub --workers 3 --cmd "codex"
skills/auto-tmux/scripts/auto-tmux.sh topology --session ai-hub
skills/auto-tmux/scripts/auto-tmux.sh scan --session ai-hub -n 80

这个封装层能做到：

先确认 target 存在。
默认对输出脱敏。
发送前打印目标上下文。
危险命令默认拒绝。
巡检、救援和录制都可重复执行。

适用场景

多个 AI CLI 并行处理互不冲突的子任务。
commander 统一分配任务、巡检 worker、收集证据。
需要观察长时间运行的安装、测试、构建或调试任务。
需要把卡住的低风险确认交给脚本化救援。
需要保留 pane 日志，用于复盘、审计和验收。

不适用场景

涉及生产数据库、云资源删除、密钥输入和敏感凭证展示。
需要图形界面、复杂交互或强实时反馈的操作。
无法接受误输入、误中断或误控制的任务。
没有明确任务边界、锁、日志和验收标准的多 Agent 并发。

采用建议

最小可用结构：

ai-hub
├── commander
├── worker1
├── worker2
└── worker3

推荐协议：

commander 负责拆任务、巡检、救援和最终验收。
worker 一次只处理一个明确子任务。
所有发送动作必须使用完整 <session>:<window>.<pane> target。
救援先 dry-run，再真实执行。
长任务必须 record，完成后汇报命令、diff、测试和风险。

风险

风险	说明	约束
误控 pane	target 错误会向错误窗口发命令	先 `topology`，再 `capture`
死循环	多个 AI 互相救援或互相触发	设置 commander 单点调度
文件冲突	多 worker 改同一文件	子任务分工和锁机制
信息泄露	capture 读到 token 或密码	默认脱敏，隔离敏感会话
幻觉放大	多 AI 同时错误执行	以测试、diff、日志和人工验收兜底

后续观察点

是否需要把 /tmp/ai_swarm/tasks.json 标准化为 schema。
是否需要增加 worker 状态机和锁文件脚本。
是否需要接入 GitHub Actions、Prometheus 或本地 Web 面板。
是否需要把 commander / worker prompt 模板独立成可复用 prompt。

9.2 KiB Raw Blame History Unescape Escape

研究