目录
§1团队化痛点
本地 AI Coding 的四个团队级缺口
直接在本地用 AI Coding 工具,短期看很方便。团队化之后,几个缺口会同时暴露。
- Prompt 没有 Review — 代码有 Code Review,prompt 没有。Agent 指令写得好不好、有没有歧义、有没有安全风险、能不能复用,往往只靠个人判断。
- 经验无法沉淀 — 日志排查步骤、部署检查方式、开发提示词通常只留在个人本地文件里,下一个人还要重新摸索。
- 过程缺少可见性 — 谁在用哪个 Agent?用了什么模型和 runtime?成功率、耗时、token 花费是多少?没有平台化就很难进入团队管理。
- 研发链路没有闭环 — Agent 写完代码不是结束。代码审查、推送、部署、提测、CR 反馈、BUG 回流和日志巡检如果仍靠人手动接力,价值就停在局部提效。
§2产品定位
EP-Harness:团队级 Agent 工作系统
EP-Harness 可以理解为一个 Managed Agents 平台。它把 Agent 当成团队里的工作成员来管理:Agent 有身份、有任务、有状态、有执行记录、有可见性、有权限边界,也有自己的 instructions、skills、runtime 和历史产出。
技术基座:EP-Harness 是基于开源项目 Multica 的二次开发。Multica 官方定位是 open-source managed agents platform,核心思路是把 coding agents 作为可分配任务、可跟踪进度、可沉淀技能的真实队友来管理;EP-Harness 在这个基座上,进一步贴合公司研发流程和内部系统。
在 EP-Harness 里,任务不是散落在聊天窗口里,而是进入 Issue。Issue 可以关联项目、需求、应用分支、工作流、评论、执行日志、文件变更和后续反馈。
- 当 Agent 的任务进入 Issue,团队就可以追踪它。
- 当 Agent 的规则进入 Instructions 和 Workflow,团队就可以审查它。
- 当 Agent 的经验进入 Skills,团队就可以复用它。
- 当 Agent 的执行进入 Runtime 和日志,团队就可以复盘它。
- 当 Agent 的结果进入部署、评审和反馈链路,团队就可以让它持续闭环。
§3架构
分层可组合架构:server · daemon · CLI
从架构上看,Multica 由三部分协作:
三个角色各司其职:
- Server 管理工作区、Issue、成员和任务队列,承担实时更新 —— 团队记忆。
- Daemon 运行在开发者本机,领取任务并调用本地 AI 编程 CLI —— 本机代理。
- AI 编程 CLI 在本地工具链和工作目录中完成实际代码执行 —— 执行现场。
§4执行契约
Backend.Execute:统一的 Agent 执行契约
EP-Harness 在 server/pkg/agent/agent.go 中以 Backend.Execute(ctx, prompt, ExecOptions) 作为各 Agent Runtime 的统一入口。agent.New 根据 agentType 和 Config 选择具体 Provider Backend。
// 各 Runtime 对上层暴露一致的生命周期 type Backend interface { Execute(ctx context.Context, prompt string, opts ExecOptions) (<-chan Event, error) } // Claude / Codex / OpenCode / ACP 各自保留协议与参数 func New(agentType string, cfg Config) (Backend, error) { ... }
server/pkg/agent 里的 Backend 接口与 claudeBackend.Execute 实现,右侧可见 antigravity / codebuddy / codex / copilot / cursor / devoco / dfsh / gemini / grok / kimi / hermes 等各 Provider Backend 文件 —— 一个契约,十余种实现Claude、Codex、OpenCode、ACP 等实现可以保留各自的参数、进程和传输协议,但对上层暴露一致的执行生命周期 —— 上层不必关心底层工具到底跑哪一家。
这一层抽象的直接收益是Runtime 可插拔。Claude 升级到新版、Codex 切换新协议、OpenCode 加入新能力,业务侧只需要改一行配置,Issue、Workflow、Skills 这些上层抽象完全不动。
§5演化模型
AI Coding 正在经历四层外扩
AI Coding 的使用方式正在经历四层变化。它们不是互相替代,而是逐层外扩:从"怎么问",走向"喂什么材料",再走向"如何执行和约束",最终走向"如何持续闭环"。
个人 AI Coding 工具通常解决前两层。EP-Harness 还解决后两层,并把四层能力放进团队研发流程。
§6内部系统
Agent 需要理解真实研发现场
通用 AI Coding 工具并不了解公司的研发体系。它不知道需求结构,不知道内部飞书文档权限,不知道应用分支如何创建,不知道代码管理和发布平台的实际流程,也不知道每个团队沉淀过哪些 Skills。
EP-Harness 的价值,就是把这些内部系统接进 Agent 的工作环境里。它要解决的不是"模型有没有能力写代码",而是"模型能不能在我们的研发流程里正确工作"。
外部工具能给你一个 Agent,EP-Harness 要给团队一个 Agent 可以工作的组织环境。
§7规程化
Prompt 从个人技巧变成团队规程
很多团队刚开始用 AI 时,会把重点放在 prompt 技巧上。但用得久了会发现,更重要的是把 prompt 变成可维护的规程。
§8上下文工程
从复制粘贴到结构化上下文
Agent 做不好,很多时候不是模型不够强,而是上下文不对。需求背景、设计文档、验收标准、关联代码仓库、目标分支、历史讨论、失败记录和内部系统调用方式,不应该靠用户每次手动复制粘贴。
EP-Harness 把这些材料变成 Issue / 需求 / 项目 / Workflow / Skills / Runtime / 飞书集成 / 运行记录 八个固定组件,由平台自动装配:
| 组件 | 承载的内容 |
|---|---|
| Issue | 任务目标、评论、状态和历史记录 |
| 需求 | 业务背景、需求文档和迭代信息 |
| 项目 | 业务边界和仓库资源 |
| Workflow | 阶段目标和交付要求 |
| Skills | 团队沉淀的方法和工具说明 |
| Runtime | 真实执行环境 |
| 飞书集成 | 通知、讨论和文档读取能力 |
| 运行记录 | 执行过程、产出和失败信息 |
这样 Agent 不再只拿到一段文字描述,而是进入一个由 Issue、项目、文档、分支、评论和运行记录组成的工作现场。
§9运行时
Harness:让 Agent 可执行、可观察、可治理
一个裸模型没有工作目录,不会天然知道当前项目怎么测试,也不会自动遵守团队规范,更不会自己接入需求管理、代码管理、发布平台、飞书和日志平台。Harness 的价值,就是在模型外面补齐这些工程能力。
这让 Agent 从"一个能说话的模型"变成"一个可管理的执行单元"。对团队来说,更重要的不是 Agent 某次回答得多漂亮,而是它能否长期稳定地在工程约束里工作。
§10闭环
Loop:把重复工作变成可控闭环
Loop Engineering 不是让 Agent 一直跑,也不是无限自动化。有价值的 Loop,需要包含发现、派发、执行、验证、记录和下一步决策 —— EP-Harness 中两类典型 Loop 已经稳定运行:
这些场景的关键不是"Agent 自动跑了",而是每一轮都有记录、判断、产出和后续动作。Loop 的价值在闭环,不在循环本身。
§11落地效果
决策追溯 · 多 Agent 协作 · 自动化治理
决策追溯
需求交付完成后,可依托 Issue 中沉淀的决策记录、实现说明,快速还原当时的实现背景和关键取舍。
多 Agent 协作
案例结论:通过将交付流程拆分为提议、开发、评审、归档等阶段,并引入多 Agent 协作机制,形成从需求澄清、实现落地、质量评审到经验沉淀的闭环,持续提升代码质量。
自动化治理
治理成效:累计自动化修复 100+ 个异常日志问题,异常日志从高频暴露逐步收敛,问题识别、归类和修复效率明显提升。典型高频问题由治理前每 4 小时 2400+ 条,降低到治理后的个位数。
§12演进路线
后续演进
§13结语
从个人工具,到团队生产力
AI Coding 的第一阶段,是个人把 Agent 当工具。下一阶段,是团队把 Agent 当协作成员。当 Agent 开始接触真实需求、真实代码、真实部署和真实反馈时,单纯依赖聊天窗口和本地 prompt 已经不够。
团队需要一个平台,把 Agent 的任务、上下文、规则、执行、审查、反馈和度量都组织起来。当这套机制跑起来,Agent 才能从一个个人电脑里的助手,慢慢变成团队研发流程里可管理、可复用、可持续优化的生产力。
个人 AI Coding 解决"我今天能不能写得更快";
EP-Harness 这类平台要回答的是"团队明天还能不能一起写得更快"。