Oh My OpenAgent 上手：给 OpenCode 系工具加一层可维护的 Agent Harness

Oh My OpenAgent 以前叫 Oh My OpenCode，最近重新站到 Agent Harness 这个位置上。它不是一个“让界面更好看”的小插件，而是围绕 OpenCode/多 Agent CLI 的一组工作流、规则、安装方式和运行习惯。现在这类项目越来越多，真正要比的不是谁的 prompt 更唬人，而是谁能把 Agent 拉回可维护状态。

先把安全话说在前面：这类项目常伴随第三方站点、安装脚本、release 包和社区镜像。README 里也明确提醒过仿冒站点风险。你要记住一条：只从 GitHub 仓库、官方 release、官方文档链接获取安装文件。不要在陌生站点输入付款信息，也不要下载所谓“增强版安装器”。Agent 工具掌握的是你的代码库权限，别稀里糊涂把门钥匙交出去。

如果你已经在用 OpenCode 或类似终端 Agent，并且发现每次都要重新解释“怎么改、先看哪里、不要碰哪里”，Oh My OpenAgent 就有价值。它把常用规则、技能和项目习惯组织成一套可重复使用的层。

如果你只是想找一个更炫的 AI 编辑器，它未必是第一选择。这个项目更偏工程工作台，重点是让 Agent 在已有代码库里少犯低级错误，而不是给你一个一键成品应用。

第一，确认仓库地址是 `https://github.com/code-yeongyu/oh-my-openagent` 或项目文档指向的官方地址。第二，看 release 和安装文档更新时间，别复制旧博客里的命令。第三，在干净测试项目里先试，不要直接把全局目录改成一锅粥。

官方 README 提到可以通过安装文档进入：

# 查看官方安装说明，不要用来路不明的镜像站
curl -s https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/refs/heads/master/docs/guide/installation.md

如果你要自动执行任何脚本，先打开读一遍。尤其看它会写入哪些目录、是否修改 shell 配置、是否安装额外依赖。终端 Agent 的权限很大，别因为一条 curl 命令省事，后面花半天排查环境。

我的建议不是“装完就全局使用”，而是在每个仓库里留下项目级说明。比如新建或更新 `AGENTS.md`：

本项目使用 OpenAgent 工作流：
1. 先阅读 README、package.json 和 tests 目录。
2. 修改前必须输出影响范围，不直接改数据库迁移。
3. 新增功能必须补测试或说明为什么不能补。
4. 涉及密钥、CI、部署配置，必须等待人工确认。
5. 每次完成后输出：改了什么、怎么验证、还剩什么风险。

这份文件比一堆炫技 prompt 更重要。Agent 每次进仓库时先读它，就知道这个项目的规矩。OpenAgent 的 harness 可以帮你承载这些规矩，但内容必须来自你的真实项目。

Agent Harness 项目通常会拉取插件、命令、规则文件。安全上要多看两眼。

这些检查不复杂，但能挡住很多糟心事。现在 AI 工具生态已经开始出现“仿冒官网”和“付费壳”，别把开源项目当 App Store。

不要拿 Hello World 试。挑一个真实但范围可控的 bug，比如“导出 CSV 时中文列名乱码”。先让 Agent 读相关模块和测试，再让它写计划。

任务：修复 CSV 导出中文列名乱码。
限制：不要改 API 返回结构；不要引入重量级依赖；保留现有导出按钮。
验收：新增一个包含中文列名的单元测试；本地 npm test 通过；输出最终 diff 摘要。

如果它能按这个流程稳定完成，说明 harness 起作用了。如果它还是一上来乱改，那就要回到规则层，而不是换模型。

Everything Claude Code 更像大而全的工程习惯库，GSD 更强调 context rot 和规格驱动。Oh My OpenAgent 的位置则更贴近 OpenCode 这条工具线：它关注如何让 OpenCode 系运行时从“能跑”变成“可长期用”。三者不一定互斥，但别一起全装。先选一个主系统，再把另外两个里的好规则摘出来。

把安装脚本、版本号和项目规则写进仓库文档；把全局改动控制在少数人试点；把安全检查列成 checklist。等它稳定减少返工，再推广到更多项目。别上来就让每个开发者都装一套，最后目录结构各玩各的。

Oh My OpenAgent 真正值得看的地方，是它代表了开源 coding agent 的第二阶段：不再只是“谁能调用模型”，而是“谁能把模型放进靠谱的工程习惯里”。这活儿不花哨，但有用。