EP-Harness Turns AI Coding Agents Into Managed Team Members

1. Team-Level Gaps in Local AI Coding

Using AI coding tools directly on a local machine is convenient in the short term, but several gaps emerge once you scale to a team.

Prompts Are Not Reviewed

Code has code review; prompts do not. Whether an agent instruction is well-written, ambiguous, carries security risks, or is reusable often depends solely on individual judgment.

Experience Cannot Be Accumulated

Log troubleshooting steps, deployment check methods, and development prompts usually stay in personal local files. The next person has to figure them out from scratch.

Process Lacks Visibility

Who is using which agent? What model and runtime are being used? What are the success rate, latency, and token cost? Without a platform, it is difficult to enter team management.

The R&D Chain Lacks a Closed Loop

An agent finishing code is not the end. If code review, push, deployment, testing, CR feedback, bug backflow, and log inspection still rely on manual handoffs, the value stops at localized efficiency gains.

The core value of EP-Harness is turning these gaps from personal habit problems into platform capabilities.

2. EP-Harness Positioning: A Team-Level Agent Work System

EP-Harness can be understood as a Managed Agents platform. It manages agents as working members of a team: agents have identities, tasks, states, execution records, visibility, permission boundaries, as well as their own instructions, skills, runtimes, and historical output.

Technical Foundation: EP-Harness is a secondary development based on the open-source project Multica. Multica's official positioning is an open-source managed agents platform, with the core idea of managing coding agents as real teammates to whom tasks can be assigned, progress tracked, and skills accumulated. EP-Harness builds on this foundation to further align with the company's R&D processes and internal systems.

Layered Composable Architecture

From an architectural perspective, Multica consists of three collaborating parts: server, daemon, and AI programming tools. The server manages workspaces, issues, members, and task queues, and handles real-time updates. The daemon runs on the developer's local machine, claims tasks, and calls the local AI programming CLI. Actual code execution happens within the local toolchain and working directory.

In EP-Harness, tasks are not scattered across chat windows but enter Issues. An Issue can be associated with projects, requirements, application branches, workflows, comments, execution logs, file changes, and subsequent feedback.

When an agent's task enters an Issue, the team can track it.
When an agent's rules enter Instructions and Workflows, the team can review them.
When an agent's experience enters Skills, the team can reuse it.
When an agent's execution enters Runtime and logs, the team can review it.
When an agent's results enter deployment, review, and feedback chains, the team can continuously close the loop.

Backend.Execute: Unified Agent Execution Contract

In EP-Harness, server/pkg/agent/agent.go uses Backend.Execute(ctx, prompt, ExecOptions) as the unified entry point for each Agent Runtime. agent.New selects a specific Provider Backend based on agentType and Config. Implementations like Claude, Codex, OpenCode, and ACP can retain their own parameters, processes, and transport protocols, while exposing a consistent execution lifecycle to the upper layer.

3. AI Coding Is Moving from Tool Usage to Engineering Systems

The way AI Coding is used is undergoing a four-layer change. These layers do not replace each other but expand outward: from "how to ask," to "what materials to feed," to "how to execute and constrain," and finally to "how to continuously close the loop."

Personal AI Coding tools typically solve the first two layers. EP-Harness also solves the latter two and integrates all four layers into the team's R&D process.

Agents Need to Understand the Real R&D Site

General AI Coding tools do not understand a company's R&D system. They don't know the requirements structure, the permissions for internal Feishu documents, how application branches are created, the actual processes of code management and release platforms, or what Skills each team has accumulated.

The value of EP-Harness is connecting these internal systems into the agent's working environment. The problem it solves is not "whether the model can write code," but "whether the model can work correctly within our R&D process."

External tools can give you an agent; EP-Harness aims to give a team the organizational environment where an agent can work.

Prompts Shift from Personal Skill to Team Protocol

When many teams start using AI, they focus on prompt techniques. But after using it for a while, they realize it's more important to turn prompts into maintainable protocols.

Context Shifts from "Copy-Paste Material" to Structured Context

An agent failing is often not because the model isn't strong enough, but because the context is wrong. Requirement backgrounds, design documents, acceptance criteria, associated code repositories, target branches, historical discussions, failure records, and internal system call methods should not rely on users manually copying and pasting each time.

Issue: Task objectives, comments, status, and history.
Requirements: Business background, requirement documents, and iteration information.
Project: Business boundaries and repository resources.
Workflow: Phase objectives and delivery requirements.
Skills: Methods and tool descriptions accumulated by the team.
Runtime: The real execution environment.
Feishu Integration: Notification, discussion, and document reading capabilities.
Run Records: Execution process, output, and failure information.

This way, the agent no longer receives just a text description but enters a work site composed of Issues, projects, documents, branches, comments, and run records.

The focus of Context Engineering is not to stuff the context full, but to let the right context enter the agent at the right time.

Harness: Making Agents Executable, Observable, and Governable

A bare model has no working directory, does not naturally know how to test the current project, does not automatically follow team conventions, and certainly does not connect itself to requirement management, code management, release platforms, Feishu, and log platforms. The value of Harness is to supplement these engineering capabilities outside the model.

This transforms an agent from "a model that can talk" into "a manageable execution unit." For a team, what matters more is not how brilliant an agent's single response is, but whether it can work stably within engineering constraints over the long term.

Loop: Turning Repetitive Work into Controllable Closed Loops

Loop Engineering is not about letting an agent run endlessly, nor is it unlimited automation. A valuable Loop needs to include discovery, dispatch, execution, verification, recording, and next-step decision-making.

Upstream Version Update Analysis

Automated scheduled checks of external releases. Determine if an analysis Issue already exists. Create an analysis task upon discovering a new version. The agent analyzes impact, risk, migration suggestions, and verification items. If implementation is needed, it further breaks down into migration sub-tasks.

Online Log Inspection

Automated pulling of anomalies by time window. Aggregation of error fingerprints, impact scope, and samples. The agent analyzes possible root causes. Generates repair suggestions and verification suggestions. Creates subsequent repair Issues when necessary.

The key to these scenarios is not "the agent ran automatically," but that each round has records, judgments, outputs, and subsequent actions. The value of a Loop lies in the closed loop, not the loop itself.

4. Implementation Results

Decision Traceability

After requirement delivery is completed, the decision records and implementation notes accumulated in the Issue can be used to quickly reconstruct the implementation background and key trade-offs at the time.

Multi-Agent Collaboration

Case conclusion: By breaking the delivery process into stages such as proposal, development, review, and archiving, and introducing a multi-agent collaboration mechanism, a closed loop is formed from requirement clarification, implementation, quality review, to experience accumulation, continuously improving code quality.

Automated Governance

Governance results: Over 100 abnormal log issues have been automatically fixed cumulatively. Abnormal logs have gradually converged from high-frequency exposure, with significant improvements in problem identification, classification, and repair efficiency. A typical high-frequency problem dropped from 2400+ occurrences every 4 hours before governance to single digits after governance.

5. Future Evolution

6. Conclusion

The first stage of AI Coding was individuals using agents as tools. The next stage is teams treating agents as collaborative members. When agents begin to touch real requirements, real code, real deployments, and real feedback, relying solely on chat windows and local prompts is no longer enough. Teams need a platform to organize an agent's tasks, context, rules, execution, review, feedback, and metrics. When this mechanism runs, an agent can gradually transform from an assistant on a personal computer into manageable, reusable, and continuously optimizable productivity within the team's R&D process.

Previous Reviews

Text / Fang Zhou

Follow Dewu Technology, technical干货 every Thursday

If you find the article helpful, feel free to comment, forward, and like～

Reprinting without permission from Dewu Technology is strictly prohibited, otherwise legal liability will be pursued according to law.