Agent 真正进入日常工作以后，瓶颈往往不在模型本身，而在运行时。聊天框能回答问题，但很难长期维护一个项目：它要记住上下文、调用工具、拆任务、写代码、跑测试、处理失败、接消息平台，还要能在长会话里恢复状态。
OpenHarness 把这个问题直接摆到了台面上。它不是另一个“套壳聊天助手”，而是一套轻量 Agent harness：tool-use、skills、memory、多 Agent 协调和长会话执行都放在一个框架里。仓库里的 ohmo 则是基于 OpenHarness 的个人 Agent，可以通过飞书、Slack、Telegram、Discord 等入口接任务，再去 fork 分支、改代码、跑测试、开 PR。
值得看的点不是“又能聊天了”，而是它把 Agent 从即时问答推进到一个可运营的工作台。开发者真正要评估的是：它能不能把任务状态、权限边界、工具调用和人类确认点管住。
先理解它的分层
OpenHarness 可以拆成两层看。
第一层是 harness。它负责 Agent 运行时的基本能力：
- 工具调用。
- Skills 加载。
- Memory 管理。
- 多 Agent 协同。
- 流式输出和 JSON 输出。
- 长任务过程里的状态记录。
第二层是 ohmo。它是一个拿来即用的个人 Agent，把 harness 能力接到消息平台和开发流程里。
这层关系很重要。只想研究 Agent runtime，可以看 OpenHarness；想直接拿一个长期在线助手，可以看 ohmo。不要把两者混成“聊天机器人”。
最小安装路径
先准备 Python 3.10 以上环境：
git clone https://github.com/HKUDS/OpenHarness.git
cd OpenHarness
python3 -m venv .venv
source .venv/bin/activate
pip install -e .如果仓库里提供了额外依赖文件，先按 README 里的方式安装：
pip install -r requirements.txt然后跑测试确认环境没散：
pytest -q如果你只是评估框架，不要一上来就接飞书、Slack 或 Telegram。先在本地跑通最小 harness，再决定要接哪个消息入口。
建一个安全的本地实验目录
给 Agent 工具链单独准备工作区：
mkdir -p ~/agent-lab/openharness-demo
cd ~/agent-lab/openharness-demo
git init把测试任务限制在这个目录里。Agent 工具最怕没有边界：一旦给了 shell 和文件权限，它就可能误改不该动的路径。
建议约定：
允许读写：~/agent-lab/openharness-demo
禁止读写：~/.ssh、生产项目、密钥目录
危险命令：rm -rf、docker prune、系统级包管理，需要人工确认这些约束最好写进项目级说明或 skill，而不是靠人临时提醒。
接入消息平台前先做三件事
第一，确认 token 和 app secret 不进仓库。
cp .env.example .env
chmod 600 .env第二，确认日志里不会打印密钥。
grep -R "print.*TOKEN\|console.log.*TOKEN" -n . || true第三，确认 Agent 的工作目录和权限范围。
pwd
git status消息入口很方便，但也会放大风险。一个群聊消息如果能触发写文件、跑命令、开 PR，那就必须把 allowlist、确认机制和审计日志放在前面。
一个靠谱的使用场景
适合先从代码维护小任务开始：
任务：给这个 Python 项目补一个 health check CLI。
要求：
1. 只改 src/ 和 tests/。
2. 先写测试，再实现。
3. 跑 pytest。
4. 输出变更摘要，不自动提交。这样的任务边界清楚，能检验 OpenHarness 的工具调用、文件修改、测试执行和结果汇报。
不建议一开始就给它：
把我们公司后台重构一下。这类任务范围太大，既不好验收，也容易让 Agent 在长链路里漂移。
上线前检查
真正接入团队之前，至少检查：
- Agent 能否限制工作目录。
- 工具调用是否有日志。
- 高风险命令是否需要确认。
- Skills 是否会误触发。
- Memory 是否会记录敏感信息。
- 消息平台是否有群组 allowlist。
- 长任务中断后是否能恢复上下文。
- PR 或提交是否需要人工审查。
OpenHarness 的价值不是“让 Agent 更像人”，而是把 Agent 变成一个能被工程管理的执行单元。能跑起来只是第一步；能限制、能恢复、能审计，才是真正能进团队工作流的开始。