标签：#agentruntime

Harness Base Definition: The Control System Outside the Model Previously, we split Agent into several minimal parts: Model: judge the next step Loop: keep the process moving Tools: interact with the real world State: keep the task connected At this point, a natural question appears: If Agent already has model, loop, tools, and state, why talk about Harness? An even easier confusion is: Is Harness a higher-level, smarter Agent that manages other Agents? That sounds plausible, but it bends the architecture in the wrong direction. Harness is not another Agent. It is not a larger prompt, and it is not a framework name. It is the control system outside the model. Continue with the same small CLI Agent: User says: help me figure out why this project's tests are failing, and fix it. If this CLI Agent is only a demo, it can be simple: send user input to model model says read file program reads file put result back into prompt model says edit file program edits file model says run tests program runs tests This chain can work once and already look like an Agent. But as soon as someone else really uses it, questions appear. What if the model wants to execute rm -rf ? What if it wants to read private files under the user's home directory? If it runs for ten minutes and the user interrupts, how is the working state saved? After a tool error, should the next model turn see the full log or only a summary? If the same task continues tomorrow, where does the session resume from? If a modification looks successful but no test verified it, how does the system know it is done? If a user says the Agent damaged a file, how do we reconstruct what happened? These questions do not belong to the model itself. They should not be left for the model to decide. The model only generates the next-step judgment from the current context. Permission, execution environment, session lifecycle, observability logs, verification criteria, and governance policy are engineering responsibilities outside the