hcom 终端编码代理协调

先解决什么问题

当你让 Claude Code、Codex、Gemini、Cursor 这类终端编码代理分工时，困难通常不在单个模型会不会写代码，而在于多个会话如何协同。代理 A 生成的计划可能要让代理 B 执行，代理 C 审查；失败后还要从某个中间状态分叉重试。若只靠复制粘贴，上下文会迅速漂移，轮次无法追踪，最后的改动也难以归因。

@user_3c6cb52e/coordinate-terminal-coding-agents-with-hcom 把 hcom CLI 包装成可被技能调用的协调层，目标是把多个终端编码代理当作可启动、可通信、可监督的代理节点。

核心能力与关键步骤

• 启动会话：用 hcom 拉起指定代理 CLI，例如 claude、codex、gemini、opencode、cursor-agent、kimi 或 copilot。
• 传递消息：把上一步的产出、失败原因或约束发给目标会话，而不是重新粘贴全部历史。
• 监控输出：持续观察各会话结果，判断是否需要继续、修正或终止。
• 分叉重试：在某个代理的中间状态上分叉，保留可复用上下文并尝试替代路径。
• 编排流水线：让不同 AI CLI 互为子代理，适合实现生成、执行、审查、修复这类多阶段流程。

使用时的关键不是“同时开很多窗口”，而是给每个代理明确角色、输入边界和期望输出：谁负责实现，谁负责检查测试，谁负责汇总 diff。每轮消息应尽量短且自包含；需要分叉时，先说明保留什么、丢弃什么，再运行 hcom 对应命令。

适用边界与注意点

它适合协调已有终端编码 CLI，不适合替代版本控制、CI 或代码评审流程。多个代理并行修改同一目录时，容易出现文件冲突、重复实现或上下文污染，建议为不同代理分配独立工作树或目录，并把合并前检查固定下来。

分叉不等于自动正确：分支可能继承错误假设或过时上下文，合并前仍需测试和 review。监控输出时也要留意敏感信息，因为终端日志可能包含代码、密钥或内部路径。总的来说，这个技能的价值在于降低多代理交接成本，但最终正确性仍取决于提示词、CLI 能力、权限边界和验证环节。