EP-Harness：从个人 AI Coding 到团队级 Agent 工作流｜得物技术

直接在本地使用 AI Coding 工具，短期看，很方便，但团队化之后会暴露出几个缺口。

• Prompt 没有 Review

代码有 Code Review，prompt 没有。Agent 指令写得好不好、有没有歧义、有没有安全风险、能不能复用，往往只靠个人判断。

• 经验无法沉淀

日志排查步骤、部署检查方式、开发提示词通常只留在个人本地文件里，下一个人还要重新摸索。

• 过程缺少可见性

谁在用哪个 Agent？用了什么模型和 runtime？成功率、耗时、token 花费是多少？没有平台化就很难进入团队管理。

• 研发链路没有闭环

Agent 写完代码不是结束。代码审查、推送、部署、提测、CR 反馈、BUG 回流和日志巡检如果仍靠人手动接力，价值就停在局部提效。

EP-Harness 的核心价值，就是把这些缺口从个人习惯问题变成平台能力。

EP-Harness 可以理解为一个 Managed Agents 平台。它把 Agent 当成团队里的工作成员来管理：Agent 有身份、有任务、有状态、有执行记录、有可见性、有权限边界，也有自己的 instructions、skills、runtime 和历史产出。

技术基座：EP-Harness 是基于开源项目 Multica 的二次开发。Multica 官方定位是 open-source managed agents platform，核心思路是把 coding agents 作为可分配任务、可跟踪进度、可沉淀技能的真实队友来管理；EP-Harness 在这个基座上，进一步贴合公司研发流程和内部系统。

从架构上看，Multica 由 server、daemon 和 AI 编程工具三部分协作：server 管理工作区、Issue、成员和任务队列，并承担实时更新；daemon 运行在开发者本机，领取任务并调用本地 AI 编程 CLI；实际的代码执行发生在本地工具链和工作目录中。

在 EP-Harness 里，任务不是散落在聊天窗口里，而是进入 Issue。Issue 可以关联项目、需求、应用分支、工作流、评论、执行日志、文件变更和后续反馈。

• 当 Agent 的任务进入 Issue，团队就可以追踪它。

• 当 Agent 的规则进入 Instructions 和 Workflow，团队就可以审查它。

• 当 Agent 的经验进入 Skills，团队就可以复用它。

• 当 Agent 的执行进入 Runtime 和日志，团队就可以复盘它。

• 当 Agent 的结果进入部署、评审和反馈链路，团队就可以让它持续闭环。

EP-Harness 在 server/pkg/agent/agent.go 中以 Backend.Execute(ctx, prompt, ExecOptions) 作为各 Agent Runtime 的统一入口。agent.New 根据 agentType 和 Config 选择具体 Provider Backend；Claude、Codex、OpenCode、ACP 等实现可以保留各自的参数、进程和传输协议，但对上层暴露一致的执行生命周期。

AI Coding 的使用方式正在经历四层变化。它们不是互相替代，而是逐层外扩：从"怎么问"，走向"喂什么材料"，再走向"如何执行和约束"，最终走向"如何持续闭环"。

个人 AI Coding 工具通常解决前两层。EP-Harness 还解决后两层，并把四层能力放进团队研发流程。

通用 AI Coding 工具并不了解公司的研发体系。它不知道需求结构，不知道内部飞书文档权限，不知道应用分支如何创建，不知道代码管理和发布平台的实际流程，也不知道每个团队沉淀过哪些 Skills。

EP-Harness 的价值，就是把这些内部系统接进 Agent 的工作环境里。它要解决的不是"模型有没有能力写代码"，而是"模型能不能在我们的研发流程里正确工作"。

外部工具能给你一个 Agent，EP-Harness 要给团队一个 Agent 可以工作的组织环境。

很多团队刚开始用 AI 时，会把重点放在 prompt 技巧上。但用得久了会发现，更重要的是把 prompt 变成可维护的规程。

Agent 做不好，很多时候不是模型不够强，而是上下文不对。需求背景、设计文档、验收标准、关联代码仓库、目标分支、历史讨论、失败记录和内部系统调用方式，不应该靠用户每次手动复制粘贴。

• Issue：任务目标、评论、状态和历史记录。

• 需求：业务背景、需求文档和迭代信息。

• 项目：业务边界和仓库资源。

• Workflow：阶段目标和交付要求。

• Skills：团队沉淀的方法和工具说明。

• Runtime：真实执行环境。

• 飞书集成：通知、讨论和文档读取能力。

• 运行记录：执行过程、产出和失败信息。

这样 Agent 不再只拿到一段文字描述，而是进入一个由 Issue、项目、文档、分支、评论和运行记录组成的工作现场。

Context Engineering 的重点不是把上下文塞满，而是让正确上下文在正确时机进入 Agent。

一个裸模型没有工作目录，不会天然知道当前项目怎么测试，也不会自动遵守团队规范，更不会自己接入需求管理、代码管理、发布平台、飞书和日志平台。Harness 的价值，就是在模型外面补齐这些工程能力。

这让 Agent 从"一个能说话的模型"变成"一个可管理的执行单元"。对团队来说，更重要的不是 Agent 某次回答得多漂亮，而是它能否长期稳定地在工程约束里工作。

Loop Engineering 不是让 Agent 一直跑，也不是无限自动化。有价值的 Loop，需要包含发现、派发、执行、验证、记录和下一步决策。

• 上游版本更新分析

自动化定时检查外部 release。 判断是否已有分析 Issue。 发现新版本后创建分析任务。 Agent 分析影响、风险、迁移建议和验证项。 需要落地时继续拆成迁移子任务。

• 线上日志巡检

自动化按时间窗口拉取异常。 聚合错误 fingerprint、影响范围和样本。 Agent 分析可能根因。 生成修复建议和验证建议。 必要时创建后续修复 Issue。

这些场景的关键不是"Agent 自动跑了"，而是每一轮都有记录、判断、产出和后续动作。Loop 的价值在闭环，不在循环本身。

需求交付完成后，可依托 Issue 中沉淀的决策记录、实现说明，快速还原当时的实现背景和关键取舍。

案例结论：通过将交付流程拆分为提议、开发、评审、归档等阶段，并引入多 Agent 协作机制，形成从需求澄清、实现落地、质量评审到经验沉淀的闭环，持续提升代码质量。

治理成效：累计自动化修复 100+ 个异常日志问题，异常日志从高频暴露逐步收敛，问题识别、归类和修复效率明显提升。典型高频问题由治理前每 4 小时 2400+ 条，降低到治理后的个位数。

AI Coding 的第一阶段，是个人把 Agent 当工具。下一阶段，是团队把 Agent 当协作成员。当 Agent 开始接触真实需求、真实代码、真实部署和真实反馈时，单纯依赖聊天窗口和本地 prompt 已经不够。团队需要一个平台，把 Agent 的任务、上下文、规则、执行、审查、反馈和度量都组织起来。当这套机制跑起来，Agent 才能从一个个人电脑里的助手，慢慢变成团队研发流程里可管理、可复用、可持续优化的生产力。

文 / 方舟

关注得物技术，每周三更新技术干货

未经得物技术许可严禁转载，否则依法追究法律责任。