Why the Harness Is the Core of an Agent: Lessons from High-Concurrency Multi-Agent Deployment in Production

Most people equate large model capability with agent capability, but the core of an agent system that runs reliably, collaborates effectively, and scales isn't the model itself—it's the orchestration structure known as the Harness. Based on a multi-agent live demo from a Bilibili tech talk, this article breaks down how production-grade projects separate "commanding" from "doing the work," and close the full loop of high-concurrency collaboration.

1. The Harness Is the Core of an Agent; the Model Is Just One Piece

The speaker opened by showing two running agents: the master controller on local port 4006, and the execution agent on port 4103. The master is the "conductor"—it doesn't do the actual work. The execution agent takes orders from the master and completes real tasks. Users only talk to the master, and the master then controls the execution agent on the user's behalf.

The key to this architecture: the large model provides the "brain," while the Harness provides the "mind" and the collaboration rules. Both agents have mind-set definitions written into their prompt context windows—the master's mindset is "commander-in-chief, sets discipline, rejects patches, documentation first," while the execution agent's mindset is "do the work." The two mindsets must align for collaboration to happen. In other words, what really determines whether an agent can finish the job is how this Harness orchestrates roles, constraints, and acceptance flows—not swapping in a stronger model.

Harness (orchestration layer) in the context of AI agents refers to the entire control and collaboration mechanism wrapped around the large model, including role definitions, task decomposition, tool invocation, state monitoring, and result validation. It doesn't change the model's own reasoning capability; it determines how the model is used. By analogy, the large model is the engine, and the Harness is the transmission and the steering wheel—no matter how powerful the engine, without a transmission it can't drive the car. The reason production-grade agent systems emphasize the Harness is that the model alone cannot guarantee consistency, traceability, and fault tolerance across multi-step tasks, and the Harness fills in these engineering properties through structured processes.

2. Master-Slave Collaboration: One Commands, One Works

The goal of the demo was to have the two existing agents autonomously develop a third agent, with no human intervention throughout. The master breaks the task into task cards (such as "M14 source code calibration" and "B13 browser visual inspection") and issues them to the execution agent as task briefs; the execution side works card by card, runs all tests, performs acceptance checks, and then reports back to the master.

What makes this flow work is a few hard constraints: task cards must be documented, the mindset prompts must match on both sides, and the division of labor must be clearly bounded. The speaker especially emphasized "documentation first" and "reject patches"—the execution agent is not allowed to bypass the spec with ad-hoc patches; every change must go back into the documentation and the process. This essentially brings software engineering's collaboration discipline into the agent system, giving multi-agent consistency a solid basis.

Task Card is a structured task description unit in agent collaboration, typically containing the task goal, input/output specs, acceptance criteria, dependencies, and so on. It turns vague natural-language instructions into executable, verifiable work orders, giving the execution agent clear boundaries and completion conditions. The task-card-driven approach draws on work-order systems and agile practices from software engineering; the goal is for every step of multi-agent collaboration to be traceable and verifiable, preventing the execution side from "freelancing" and drifting from expected results.

3. Three Iterations: From Fully Automated Run-Through to Clearing Obstacles

The demo advanced in three passes. In the first pass, the master ran through all nine stages in one go with no developer involvement—just to see the result. In the second pass, the developer said, "Arrange it yourself, I won't step in anymore," and the master independently completed planning and execution. The third pass targeted the problems exposed in the first two—such as sandbox traffic interception and tests being downgraded—with the master clearing obstacles in advance before starting.

The process reveals an easily overlooked fact: high concurrency in agents isn't about spinning up a bunch of instances at once—it's about the master being able to continuously schedule, monitor, and validate across multiple stages and multiple task cards. The speaker mentioned the master would "keep tabs" on whether the execution side was doing things right, showing that the Harness also embeds monitoring and validation. Before the third pass started, the master first did a "Stage A concept comparison" and then moved into execution—bringing pre-validation into the orchestration as well.

AI Native means building from product design to workflow with AI capability as the core premise, rather than attaching AI as an add-on tool to traditional processes. In the context of agent development, AI Native means the developer's role shifts from "hand-writing every line of code" to "designing the Harness, writing mindset prompts, defining task cards and acceptance criteria"—from executor to commander. The concept emphasizes that organizations and processes need to be redesigned around AI's capability boundaries, rather than simply cramming AI into old development models.

4. What Scenarios Can This Framework Be Applied To

The speaker explicitly said that "developing a third agent" in this framework can be replaced with social media workflows (Douyin, Xiaohongshu, etc.), finance-related agents, or any task that needs process organization. What changes is the work the execution side has to do; what stays the same is the Harness layer—master plus execution, aligned mindsets, task-card-driven work, and a closed acceptance loop.

For production-grade projects, this means the focus of deployment should be on three things: write collaboration discipline into the mindset prompts, break tasks into verifiable task cards, and let the master handle scheduling and monitoring. Model choices can change, but the skeleton of the Harness must not fall apart. This is also what the speaker repeatedly emphasized about "AI Native"—it's not about going back to the era of hand-typing every line of code, but about learning to command large models well and keeping them from going off track.