Lite-Harness 实战指南：用统一服务器管理团队的 AI 编码 Agent

痛点：一个团队，N 个 AI 编码 Agent，怎么管？

如果团队同时使用 Claude Code、Codex CLI、OpenCode 三个工具，每个都需要单独启动服务器、配 MCP 工具、管理工作目录和 session 状态。更麻烦的是——成员 A 写了一个 MCP 工具，成员 B 还得复制一遍配置。

Lite-Harness 是 LiteLLM Labs 最近开源的项目（MIT 协议），它把多个 AI 编码 Agent 统一到一个 Docker 容器中管理，提供共享的 MCP 工具、提示词模板、session 持久化和沙箱隔离，同时支持 CLI、API 和 Slack 三种使用方式。

一句话总结：如果你团队在用 2 个以上的 AI 编码 Agent，Lite-Harness 能省掉你 70% 的运维成本。

核心特性速览

快速部署

第一步：安装

npx skills add LiteLLM-Labs/lite-harness -g

然后在你喜欢的 AI 编码 Agent 中执行：

/lite-harness-setup

第二步：手动部署（Docker）

如果你习惯手动管理：

export MASTER_KEY=$(openssl rand -hex 32)
echo "MASTER_KEY: $MASTER_KEY"

docker run -p 4096:4096 \
  -e LITELLM_API_BASE=https://your-litellm-gateway \
  -e LITELLM_API_KEY=*** \
  -e MASTER_KEY="$MASTER_KEY" \
  ghcr.io/litellm-labs/lite-harness:latest

打开 localhost:4096，输入 Master Key 登录。需要一个正在运行的 LiteLLM 网关作为模型后端。

第三步：持久化

默认容器重启后 session 会丢失。要保留历史上下文，挂载持久化存储：

docker run -p 4096:4096 \
  -v ./data:/home/sandbox/.local/share/lite-harness \
  -e LITELLM_API_BASE=... \
  -e LITELLM_API_KEY=*** \
  -e MASTER_KEY="$MASTER_KEY" \
  ghcr.io/litellm-labs/lite-harness:latest

重启后可以在日志中看到 hydrated N session(s) from db，所有之前的对话会话都恢复可用。

实战场景：GitHub Star 自动回访 Agent

来看一个具体的例子——创建一个定时运行的 GitHub Star 回访 Agent，自动发现新的 star 用户，并在 LinkedIn 上发送感谢私信。

/deploy-agent

部署后会看到类似输出：

✓ Checking capabilities... sandbox=e2b vault=available cron=supported
✓ Stored vault key BROWSER_USE_API_KEY
✓ Stored vault key LINKEDIN_PROFILE_ID
✓ Created agent: agent_abc123 (opencode · claude-sonnet-4-6)
✓ Attached vault keys + scheduled 0 */4 * * 1-5 America/Los_Angeles
✓ Test run started: run_xyz789
→ Logs: https://lite-harness.onrender.com/api/agents/agent_abc123/runs/run_xyz789/logs
→ UI: https://lite-harness.onrender.com/agents

关键点：

• Agent 运行在 E2B 沙箱中，不影响宿主环境
• Vault 自动管理敏感凭证（API Key、Profile ID）
• 每条消息发送前进入 Inbox 审批队列，人工确认后才执行
• 定时任务使用标准 cron 表达式

沙箱配置

要启用沙箱隔离，设置环境变量即可：

设置后每个 Agent 运行在自己的 Linux 沙箱中，支持模板、快照、密钥管理等高级功能。

对比：独自运行 vs Lite-Harness

最佳实践

1. 搭配 LiteLLM Proxy 使用：Lite-Harness 需要一个 LiteLLM 网关做模型后端。如果你还没用，可以先用 LiteLLM 统一管理所有模型 API，再通过 Lite-Harness 暴露给团队。

1. 生产环境用 Docker Compose：

version: '3'
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
  lite-harness:
    image: ghcr.io/litellm-labs/lite-harness:latest
    ports:
      - "4096:4096"
    environment:
      - LITELLM_API_BASE=http://litellm:4000
      - LITELLM_API_KEY=${LITELLM_API_KEY}
      - MASTER_KEY=${MASTER_KEY}
    volumes:
      - ./data:/home/sandbox/.local/share/lite-harness
    depends_on:
      - litellm

1. 敏感信息走 Vault 管理：不要在 Agent 代码中硬编码 API Key。Lite-Harness 的 Vault 机制会自动将凭证注入沙箱环境，日志输出时自动脱敏。

1. 团队共享 MCP 工具：写好一个 MCP 工具（如数据库查询、GitHub API 调用），所有通过 Lite-Harness 部署的 Agent 都能直接使用，不需要每个成员重复配置。

总结

Lite-Harness 解决的真正问题不是”又一个 Agent 框架”，而是多 Agent 多成员团队协作时的配置碎片化。如果你已经用上了 LiteLLM 管理模型 API，那 Lite-Harness 就是补齐最后一公里的工具——把你的 Claude Code、Codex、OpenCode 全部收归到一个统一的管理界面下。

GitHub: github.com/LiteLLM-Labs/lite-harness Docker: ghcr.io/litellm-labs/lite-harness:latest 许可证: MIT