Abstract

As Large Language Models (LLMs) continue to improve, artificial intelligence systems are gradually evolving from question-answering chatbots into AI agents capable of continuously perceiving their environments, invoking tools, maintaining state, and completing complex tasks. Compared with traditional conversational systems, the key change introduced by agents is not merely that “the model can call tools,” but that the model is placed inside an operational environment containing context, memory, tools, permissions, feedback, and recovery mechanisms, and completes tasks through a continuous observation–decision–action loop. Therefore, understanding AI agents should not stop at Prompt Engineering or the capability of a single model; it should instead examine, from a systems-engineering perspective, the relationships among the model, Context, Tools, Memory, Evaluation, and the surrounding Harness.

This report is based on the core framework of Li Bojie’s AI Agents in Depth: Design Principles and Engineering Practice, and follows the content sequence of the system presentation. It systematically reviews the basic agent paradigm, context and memory, RAG, tools and Coding Agents, interaction and Harness Engineering, evaluation and continual improvement, and Multi-Agent collaboration. On this basis, it further examines four representative contemporary agent systems—OpenClaw, Hermes Agent, OpenAI Codex, and Anthropic Claude Code—and analyzes the differences in their Harness designs with respect to persistent availability, continual learning, parallel engineering execution, and developer control. This report argues that, as base-model capabilities gradually converge, competition among agent products is shifting from pure model-capability competition toward competition in system capabilities such as Context, Memory, Tools, Permissions, Verification, Recovery, and Orchestration—that is, from “model competition” toward “Harness competition.”

Keywords: AI Agent; Large Language Model; Context Engineering; RAG; MCP; Harness Engineering; Coding Agent; Multi-Agent; OpenClaw; Hermes; Codex; Claude Code

---

1. The Basic Paradigm of AI Agents: From Answer Generation to Closed-loop Action

The task of a traditional chatbot can usually be described as “given an input, generate a response of the highest possible quality.” The objective of an AI agent is clearly more complex. An agent must not only understand user intent, but also continuously acquire information in a dynamic environment, maintain task state, select the next action, and adjust subsequent decisions according to the result of that action. The system therefore changes from an “input–output” structure into a closed loop of “observation–reasoning–action–observation again.”

At the most basic system level, an agent can be abstracted as:

Agent = LLM + Context + Tools

Here, the LLM is the decision core, responsible for understanding, reasoning, and planning; Context determines what the model can currently see, including user requests, system instructions, historical trajectories, tool results, memory, and external knowledge; Tools determine what the model can do to the external world, such as retrieving web pages, executing code, editing files, sending messages, or operating a GUI. These three elements are not independent modules; together they determine the behavioral outcome of each Agent Loop.

The most typical manifestation of this loop is ReAct, namely Reasoning + Acting. Unlike approaches that try to complete all reasoning in one pass, ReAct emphasizes alternation between reasoning and action: the agent first observes the current environment, makes a one-step decision, executes an action, writes the tool return or environmental change back into Context, and then decides what to do next. Uncertainty in real tasks can therefore be absorbed into later observations. In a web-retrieval task, for example, an agent may first search for a keyword, discover that the results are insufficiently precise, reformulate the query, and then open a more relevant page. This closed-loop capability is an important distinction between agents and traditional scripts or static conversational systems.

However, more autonomy is not always better. Workflow and Autonomous Agent actually form a continuum. For fixed, auditable, or high-risk processes, a deterministic Workflow may be more reliable than a highly autonomous agent; greater autonomy becomes advantageous only when task paths are difficult to enumerate in advance, environmental feedback changes frequently, and the model must plan dynamically. Therefore, the objective of agent engineering is not to “hand as many decisions as possible to the model,” but to design the model’s decision boundary appropriately according to task complexity.

This point also leads to a further conclusion: when an agent fails, it does not necessarily mean that a stronger model must be trained. Many errors arise from missing context, lost state, poor tool design, insufficient permission configuration, or missing validation mechanisms. Compared with directly changing model parameters, modifying Context, Skills, Tools, or programmatic constraints is usually easier to attribute, verify, and roll back. This principle runs through the subsequent discussion of agent engineering.

---

2. Context, Memory, and RAG: How Agents Form a Sustainable “Observation Space”

If the LLM is the “brain” of an agent, then Context is closer to the agent’s current “perceptual space” and “working memory.” A real agent inference call may contain far more than the user’s current question. It may simultaneously include the System Prompt, conversation history, Tool Definitions, Tool Calls, Tool Results, long-term Memory, RAG retrieval results, Skills, task state, and even information returned by subagents. Context Engineering therefore does not focus on how a single Prompt should be phrased, but on how the information truly needed for the current decision should be selected and organized within a limited context window.

From a systems perspective, Context can be compared to the operating system of an agent. The current stage of task execution resembles process state; Tool Definitions resemble system-call interfaces; Tool Results are returns from the external environment; Memory is persistent state across Sessions; Skills are capability modules loaded on demand. This perspective shows that Context should not be understood as “a longer chat history,” but as a core state-management mechanism of the Agent Runtime.

The physical organization of Context can even directly affect performance cost. Consider KV Cache and Prompt Cache: when a Transformer processes a repeated prefix, it can reuse previously computed Key/Value representations, thereby reducing latency and compute cost. Production systems therefore tend to keep stable content as a stable prefix, while placing frequently changing task state, tool output, and temporary evidence later in the sequence. Context Engineering thus affects both model behavior and inference cost and system throughput.

As agent capabilities increase, another problem appears: the context window cannot contain every tool, rule, and item of knowledge. The Progressive Disclosure embodied by Skills therefore becomes important. A Skill can contain instructions, rules, scripts, tools, and verification methods for a particular type of task, but the system does not need to place the full content of every Skill permanently into the System Prompt. A more reasonable approach is to first provide the model with a capability catalog and load the detailed content of a Skill only when the task truly requires it. This reduces Token consumption and also lowers selection noise when the model faces too many candidate capabilities.

Long tasks also require Context Compression. Unlike the simplistic approach of “asking the model to summarize the history,” mature systems distinguish between information with different lifecycles. Large logs, complete web pages, and one-time tool outputs are short-lived information that can be trimmed or externalized; intermediate decisions and previously attempted paths should be preserved as structured summaries; genuinely long-term user preferences, stable conclusions, and work methods should be distilled into Memory or Skills. The goal of compression is not merely to shorten text, but to preserve the critical state and causal information required for future decisions while reducing redundancy.

Memory and Knowledge Base are also two concepts that are easily confused in agent systems. Memory primarily describes “what has happened in the past to this user, this agent, or this long-running task,” such as user preferences, historical decisions, persistent task state, and prior experience. A Knowledge Base mainly provides external knowledge, such as enterprise documents, academic papers, product databases, or web materials. Both may eventually enter Context, but their lifecycles and governance methods differ: Memory focuses more on identity, updating, conflict, and forgetting, whereas a Knowledge Base focuses more on document segmentation, retrieval, recall, freshness, and evidence provenance.

The truly difficult part of Memory Engineering is not “storing content,” but continuously organizing it. A mature memory lifecycle must extract candidate memories from evidence, verify them and detect conflicts, merge them into existing memory with minimal modification, and preserve the ability to audit and roll back changes. For example, if the old memory says “the user likes morning meetings,” while new evidence explicitly says “do not schedule morning meetings anymore,” then simply appending both statements will expose the model to conflicting facts in future. A mature system should instead identify the update relationship and modify the existing state.

Compared with Memory, RAG (Retrieval-Augmented Generation) addresses how external knowledge enters Context at task time. Its basic process can be summarized as Retrieve, Augment, and Generate: first retrieve evidence relevant to the current question, then insert that evidence into the current context, and finally let the model generate a result based on those materials. The value of RAG is that the model does not need to permanently encode all knowledge into its parameters in order to use up-to-date information, private enterprise material, or citable evidence.

Production-grade RAG is usually not based on a single vector-retrieval mechanism. Dense Retrieval uses Embeddings to find semantically similar content in vector space, while Sparse Retrieval or BM25 is often better at handling keywords, identifiers, proper nouns, and exact phrases. In practice, systems commonly combine both types of results and then use a Re-ranker to perform more precise relevance ordering over the candidate content. This shows that the key to RAG is not merely “connecting a vector database,” but retrieval quality and evidence governance. If the retrieved content is incorrect, stale, or incomplete, the final generated result may still fail.

---

3. Tools, MCP, and Coding Agents: From Language Generation to Real Execution

With Context alone, the agent merely “sees more clearly”; only with Tools can the model actually change the external environment. The essence of Tool Calling is to transform the model from producing natural-language suggestions into producing structured actions. The model no longer merely says “I recommend searching the weather,” but explicitly outputs a tool name and parameters that conform to a Schema. The system executes the action and then writes the Tool Result back into Context. In this way, the language model is connected to deterministic software interfaces.

A reliable tool requires a clear name and description, explicit parameter types, appropriate permission boundaries, understandable error semantics, and results that are as verifiable as possible. If tool descriptions are vague, parameters are overly complex, or permissions are unlimited, even a strong model may make incorrect selections or unsafe calls. Tool Design itself is therefore part of the Agent Harness.

MCP (Model Context Protocol) further addresses the problem of how tools and resources can be connected in a standardized way. Its value can be compared to providing a common “socket” for agents: external services can expose tools, resources, or context through the same protocol, allowing different agent clients to reuse these capabilities more easily. MCP does not make the model itself smarter, nor does it directly solve questions such as “which tool should be called” or “whether the result is trustworthy.” Its primary contribution is reducing engineering adaptation costs between different tools and agents.

When the number of tools scales from dozens to hundreds or even thousands, a new Context problem appears. Exposing every tool Schema to the model at once increases Token consumption and enlarges the space of incorrect choices, so production systems often introduce Tool Discovery: first identify a small number of candidate tools through categories, indexes, or search, and only then dynamically load the complete definitions of those candidates into the context. This is essentially the same system-design principle as the progressive disclosure used by Skills.

Among different types of agents, Coding Agents are especially important because code is not merely an ordinary tool; it is a “meta-tool capable of creating new tools.” A Coding Agent can read a repository, search for relevant code, edit files, run tests, read errors, and revise again, thereby forming a highly verifiable loop. Over decades, software engineering has accumulated compilers, type systems, unit tests, CI, lint, Runtime Errors, Git diffs, and Pull Request Reviews—mechanisms that naturally provide rich feedback for agents.

This is also a major reason Coding Agents have matured relatively quickly. They do not depend on “getting everything right in one attempt”; instead, they depend on the environment repeatedly telling them whether the last change worked. When an agent can safely execute its own scripts inside a Sandbox and package verified programs into new Tools or Skills, it can even achieve a degree of Self-bootstrapping: when encountering a new task type, it can search for existing capabilities or write scripts itself, then distill successful methods for later reuse. As a result, many general-purpose agents are gradually taking on a system form resembling “Coding Agent + Sandbox + Tools.”

---

4. From Interaction to Harness Engineering: The True Core of Production-grade Agents

When agents move from chat windows into real environments, they are no longer merely synchronously responding to user input; they increasingly become event-driven systems. Tasks can be triggered by user messages, Email, Webhooks, Cron timers, system alerts, or even other agents. Tasks may also be paused, resumed, executed in parallel, or continue running in the background. At this point, the importance of state management, event deduplication, concurrency control, and recovery mechanisms rises rapidly, and agent engineering begins to overlap substantially with traditional distributed systems and Workflow Engines.

Multimodal interaction further amplifies this system complexity. A real-time voice agent often needs to pass through VAD (Voice Activity Detection), ASR (Automatic Speech Recognition), the LLM, and TTS (Text-to-Speech). The bottleneck in actual user experience is often not the quality of any single model, but end-to-end latency. Therefore, streaming, parallel execution, user interruption, and layered fast/slow reasoning are often more important than simply improving model accuracy.

Computer Use expands the agent’s Observation Space and Action Space to the GUI. The model can perceive pages through screenshots, DOM, or other structured interface information, and then perform actions such as clicking, typing, scrolling, and using keyboard shortcuts. However, “being able to click” is far from the same thing as “being able to complete the operation stably and safely.” Changes in page layout, pop-ups, login state, permission confirmation, and irreversible actions all create new failure modes. GUI agents therefore make one point particularly clear: the real product barrier is often not whether the model has a capability, but whether the system can control, verify, and recover that capability.

Accordingly, the understanding of agent engineering has gradually evolved from Prompt Engineering to Context Engineering and then further to Harness Engineering. This evolution can be summarized as an inclusion relationship:

Prompt ⊂ Context ⊂ Harness

Prompt Engineering concerns how to instruct the model; Context Engineering concerns what the model can currently see; Harness Engineering concerns how the entire runtime system around the model operates. A Harness usually includes Context, Memory, Tools, Cache, Permissions, Sandbox, Validation, Error Recovery, State Management, Parallelism, Observability, and Safety.

Therefore, a production-grade agent is better understood through the following formula:

Agent = Model × Harness

The “multiplication” here emphasizes a weakest-link effect. A strong model inside a weak Harness may be “smart but out of control”; a highly polished Harness around a model without sufficient understanding and reasoning ability may be “stable but unable to solve complex tasks.” The same base model placed in different Harnesses may therefore produce very different user experiences, which is one fundamental reason modern agent products are increasingly differentiated.

A reliable Harness must cover at least three stages. The first is Constraint before action, including least privilege, tool allowlists, Fail-closed behavior, Sandbox isolation, and confirmation for high-risk operations. The second is Verification after action, including Schema validation, automated tests, Validators, Policy Checkers, Hooks, or independent Reviewers. The third is Recovery after failure, including Retry, Backoff, Circuit Breakers, Model Fallback, Checkpoints, State Rollback, and Human Takeover. Safety and reliability are therefore not an additional “protection layer” added at the end, but system properties spanning the entire agent lifecycle.

---

5. Evaluation, Continual Improvement, and Multi-Agent: How Agents Actually Become Better

If an agent system cannot be evaluated reliably, it is impossible to determine whether a change has actually improved or degraded it. Compared with traditional model evaluation, Agent Evaluation must consider three levels simultaneously: result, process, and system. Result-level evaluation asks whether the task was ultimately completed; Trajectory-level evaluation asks whether the entire execution trajectory was reasonable and where the first error occurred; System-level evaluation further considers cost, latency, robustness, and safety.

Pass@k is a common metric in agent evaluation. It indicates that, if the model is allowed k independent attempts and at least one succeeds, then the task is in some sense “within the system’s capability.” Production environments, however, care more about single-attempt success and repeated success. An agent with an apparently high per-step success rate may still suffer rapidly declining end-to-end success in long-chain tasks because errors accumulate. Therefore, upper-bound single-task capability and operational reliability must be distinguished.

LLM-as-a-Judge is a common automated evaluation method, in which another LLM scores a result or trajectory according to a predefined Rubric. More important than the final score, however, is Failure Attribution: did the first error occur in Context, RAG, Tool use, Reasoning, Verification, or Recovery? Only after locating the failure mechanism can an engineering team know which layer should be modified, rather than simply “switching to a stronger model” based on intuition.

Mature agent development should form a loop similar to scientific experimentation: observe failures from Benchmarks or production logs, propose mechanism-level hypotheses, verify changes through Ablation, A/B Tests, or Feature Flags, and then add critical historical failures to a Regression Set. In other words, Agent Engineering should not rely on “it feels smarter,” but on reproducible and falsifiable experiments.

Only when the error truly originates in the model itself should further training be considered. Mid-training is more suitable for cases where the base model’s knowledge or capability distribution is insufficient; SFT (Supervised Fine-Tuning) is appropriate when the model “knows how to do the task, but the behavioral protocol is unstable”; RL (Reinforcement Learning) is more suitable when multiple viable strategies exist and reward signals can increase the probability of better behavior. Not every agent problem deserves RL. Many issues are easier to control through changes to Context, Skills, Tools, Hooks, or programmatic rules.

This leads naturally to the problem of continual improvement. Context Learning is not the same as Persistent Learning. If an agent completes ten thousand tasks today but none of the experience is written back to a durable substrate, a new Session tomorrow may still repeat yesterday’s mistakes. Experience can be written into Knowledge, Instructions / Skills, Programs, or Model Parameters. From an engineering perspective, outer-layer mechanisms that are auditable and reversible should usually be modified first. For example, if an agent repeatedly forgets to run tests before deployment, adding a mandatory Hook is often more reasonable than retraining the model.

Multi-Agent further expands system parallelism and specialization, but it does not mean “the more agents, the better.” A second agent is genuinely valuable only when it brings new information, tools, permissions, expertise, or true parallelism. If multiple agents use the same model, the same Context, and similar Prompts, their errors are often highly correlated, and majority voting does not necessarily provide independent judgment. Therefore, the core value of Multi-Agent systems should be understood as heterogeneous capabilities and division of responsibility rather than quantity itself.

---

6. Engineering Practice of Popular Agents: OpenClaw, Hermes, Codex, and Claude Code

Within the theoretical framework above, OpenClaw, Hermes Agent, Codex, and Claude Code can be understood as four different Harness implementation strategies. They are often grouped together as “popular agents,” but they are not completely homogeneous in system positioning. OpenClaw emphasizes persistent presence and cross-channel access, Hermes emphasizes the learning loop formed by long-term Memory and Skills, Codex emphasizes Multi-Agent parallel engineering execution and task orchestration, and Claude Code emphasizes programmable developer control over the Harness.

6.1 OpenClaw: A Channel-first Persistent Personal Agent

The core of OpenClaw can be understood as a self-hosted Gateway. Different channels such as Telegram, WhatsApp, Slack, Discord, and WebChat first connect to the Gateway. The Gateway then manages long-term state such as Sessions, Routing, Memory, Tools, Skills, Cron, and Webhooks, and delegates the parts requiring reasoning to the model. Compared with typical Coding Agents, OpenClaw focuses more on whether “the agent is always there,” making it closer to Personal Agent Infrastructure.

This characteristic is especially visible in long-running tasks. The official OpenClaw Showcase includes a community case in which an agent negotiated continuously with multiple car dealers through Email, with the community author reporting a final saving of $4,200. This figure is a user-reported claim and should not be treated as an independent Benchmark; what matters more is the structure of the task itself. The agent must read multiple email threads over a long period, maintain different offers and conditions, adjust strategy according to new feedback, and return control to the user at critical decision points. Compared with a one-shot Chatbot, such tasks truly depend on cross-time state, asynchronous events, and persistent presence.

OpenClaw can therefore be summarized as Channel-first. What it expands is not merely single-step reasoning capability, but the agent’s “space of presence”: the agent can continuously exist across multiple devices, messaging platforms, and automation workflows.

6.2 Hermes Agent: A Learning-first Continual-learning Agent

Nous Research positions Hermes Agent as a self-improving agent. Here, “self-improvement” is currently more appropriately understood at the Harness layer: past experience is continuously written back into the system through Persistent Memory and Skills, rather than necessarily meaning that model parameters are continuously trained online during operation.

Hermes can store facts, preferences, and historical experience in long-term Memory, while distilling “how a certain type of task should be completed” into Skills. After a task is completed, corrections can update Memory, stable workflows can create or modify Skills, and later tasks can reuse these capabilities. Combined with Cron, Subagents, Bot Mode, MCP, and long-running environments, Hermes forms a clear Learning Loop.

In Hermes’s official User Stories, Teknium from Nous Research described running 12 Hermes instances in parallel every day for Hermes development, backend-infrastructure investigation, and work involving RL Environments, Benchmarks, and Datasets. What truly matters here is not the number “12,” but that multiple persistent agent instances take on different roles while continuously retaining their own experience and state. Hermes is therefore closer to a Learning-first Persistent Agent Harness.

6.3 Codex: An Orchestration-first Engineering Execution Platform

Codex was initially most easily understood as a Coding Agent, but by 2026 its product form had clearly expanded toward Multi-Agent engineering execution and task orchestration. Current Codex workflows can coordinate through ChatGPT, IDE, CLI, and Cloud Environments, while Worktrees and cloud sandboxes allow multiple agents to work simultaneously on Features, Bugfixes, Refactors, or Research tasks.

Git Worktree is especially important here because it allows the same Repository to have multiple independent working directories at the same time. Agent A can work on one Feature while Agent B fixes a Bug without directly contaminating each other’s Git state. As a result, the basic collaboration unit in software development gradually shifts from “one developer and one AI pair” to “one developer supervising multiple parallel agent workstreams.”

OpenAI disclosed an Agent-first engineering experiment in its Harness Engineering case study: starting from an empty Git Repository, the project grew to roughly one million lines of code and about 1,500 Pull Requests in approximately five months, initially driven by 3 engineers and later expanded to 7. The team also provided an internal estimate that the entire project took roughly one-tenth the time of manual coding. Because these figures come from OpenAI’s own experiment, they should not be directly generalized as a universal productivity Benchmark.

The more important conclusion from this case is the change in engineering roles. Developers increasingly focus on designing Agent-friendly Repositories, task specifications, tests, CI, AGENTS.md, Skills, Observability, and automated Review, while the agent performs implementation. OpenAI summarized this relationship as: Humans steer. Agents execute. This is also why Codex can be characterized as Orchestration-first: its core value is not merely writing code, but organizing multiple agents to advance engineering tasks reliably.

6.4 Claude Code: A Harness-first Developer Agent

Claude Code follows a somewhat different path from Codex. It also has strong Coding capabilities, but Anthropic places greater emphasis on how developers can control the agent precisely. Mechanisms such as CLAUDE.md, Rules, Skills, Subagents, Hooks, MCP, and Plugins together form a highly programmable Developer Harness.

CLAUDE.md is a representative form of persistent project-level Context. Developers can record project architecture, coding conventions, test commands, prohibited actions, and team agreements in it, so that the agent receives stable background information each time it enters the project. Hooks go further by turning some soft constraints into deterministic program mechanisms. For example, if “tests must be run before submission” appears only in a Prompt, the model may still forget it; if a Hook automatically runs tests before submission, the requirement no longer depends on whether the model remembers the rule.

Anthropic’s Data Infrastructure team disclosed a Kubernetes troubleshooting case: after the cluster stopped scheduling Pods, Claude Code combined Dashboard screenshots, the Google Cloud interface, documentation, and commands to investigate the issue step by step, eventually identifying exhausted Pod IP addresses and providing the steps for creating a new IP Pool and attaching it to the cluster. This case shows that Claude Code is no longer merely a completion tool inside a code editor, but can place screenshots, web interfaces, Shell commands, and cloud systems into a single Agent Trajectory. The real difficulty remains the Harness: which operations may execute automatically, which require confirmation, how results are verified, and how execution is stopped or recovered when something goes wrong.

Claude Code is therefore best summarized as Harness-first. Its value lies in exposing many Agent control points directly to developers, allowing model behavior to be jointly constrained by rules, Hooks, Subagents, and external tools.

---

7. Cross-comparison and Engineering Selection of the Four Agents

From a product perspective, OpenClaw, Hermes, Codex, and Claude Code all contain Models, Context, and Tools, but they make different trade-offs around the task lifecycle.

Dimension	OpenClaw	Hermes Agent	Codex	Claude Code
Core positioning	persistent personal Agent Gateway	continual-learning general-purpose Agent	Multi-Agent engineering execution platform	programmable developer Harness
Main strategy	Channel-first	Learning-first	Orchestration-first	Harness-first
Main interfaces	messaging platforms / Web / CLI	Desktop / CLI / Bots / messaging platforms	ChatGPT / IDE / CLI / Cloud	Terminal / IDE / Desktop / Web
Long-term Memory	strong	core capability	increasingly integrated into long-running workflows	project Context + Memory mechanisms
Skills	supported	core learning substrate	supported	supported
Background and automation	Cron / Webhook / Automation	Cron / Routine	Automations / Background Work	Background / external orchestration
Multi-Agent	Routing / Subagents	Subagents / Bot Mode	core strength	Subagents
Core advantage	persistent presence and multi-channel access	experience retention and continual learning	parallel engineering and task orchestration	high controllability and programmability
Typical scenarios	Personal Assistant	Persistent / Research Agent	large engineering workflows	Developer-controlled Agent

If the goal is to build a 24/7 digital assistant that works across devices and messaging platforms, OpenClaw’s Gateway and long-term Session architecture are a natural fit. If the emphasis is on Memory, Skills, and a continual-learning loop, Hermes is more representative. If the goal is large-scale software engineering, multi-task parallelism, and orchestration among multiple agents, Codex is better suited as an Orchestration platform. If developers want precise control over Agent Context, rules, Hooks, Subagents, and external tools, Claude Code is more appropriate.

Therefore, engineering selection should not begin by asking “Which Agent is the strongest?” but by asking what the core task lifecycle actually is. The four products jointly demonstrate that the same underlying model capability can produce very different product behaviors and interaction models when embedded in different Harnesses.

---

8. Conclusion: From Model Competition to Agent Systems Engineering

The essence of an AI Agent is not simply adding several tools to a Large Language Model, but constructing a complete system capable of continuously perceiving, acting, verifying, correcting, and accumulating experience. At the basic structural level, its capabilities can be described by Agent = LLM + Context + Tools. From an engineering perspective, as system complexity increases, a more appropriate framework becomes Prompt ⊂ Context ⊂ Harness, which ultimately converges on Agent = Model × Harness.

Context determines what the Agent sees; Memory and RAG determine how information enters the system across time and from external knowledge sources; Tools and MCP determine how the Agent converts language-level decisions into real actions; Coding Agents and Computer Use expand its execution space; Permissions, Validation, Recovery, and Evaluation determine whether those capabilities can truly be used in production. Continual improvement and Multi-Agent are not isolated add-on features, but further extensions of temporal scale and parallel scale after the preceding system capabilities become mature.

OpenClaw, Hermes, Codex, and Claude Code demonstrate different forms of modern Agent Harness from four directions: persistent presence, continual learning, parallel labor, and developer control. Together, they reveal a broader trend: as base-model capabilities continue to improve, increasingly large differences among products will come from system design outside the model. The future competition will concern not only “which model is smarter,” but also “what the system lets the model see, what it allows the model to do, how it verifies that the model acted correctly, how it recovers from mistakes, how experience is written back, and how multiple agents cooperate.”

Therefore, the next stage of AI Agents is better understood as Agent Systems Engineering. If the early question of the Large Language Model era was “Can machines demonstrate complex reasoning ability through language?”, then the practical problem faced by Agent Engineering is:

How can machines perform work in real environments over long periods of time, reliably and under control?

---

Appendix A: High-frequency Terms and Acronyms

This appendix is intended for quick reference. Key acronyms are also explained when they first appear in the main text. The appendix does not alter the eight-section structure of the main report.

Term / Acronym	Full name and meaning
AI	Artificial Intelligence
Agent	an intelligent system capable of perceiving an environment, maintaining state, making decisions, and executing actions
LLM	Large Language Model
ReAct	Reasoning + Acting, an Agent paradigm that alternates reasoning and action
Observation	new information obtained by the Agent from users, tools, or the environment
Context	all information visible to the model during the current inference step, including Prompt, history, tool results, Memory, and RAG evidence
System Prompt	system-level instructions defining the model’s role, principles, constraints, and high-level behavior
Token	the basic discrete unit used by the model to process text
KV Cache	Key-Value Cache, caching of Keys and Values in Transformer Attention
Prompt Cache	a product-level caching mechanism for reusing repeated prompt prefixes
Skill	an on-demand, reusable Agent capability package that may include instructions, rules, scripts, tools, and verification methods
Memory	user state, preferences, facts, and experience persistently stored across Sessions or tasks
Knowledge Base	a collection of documents, databases, or other sources used for external knowledge
RAG	Retrieval-Augmented Generation
Embedding	encoding text, images, or other content into vector representations
Dense Retrieval	dense semantic retrieval based on vector similarity
Sparse Retrieval	sparse retrieval based on lexical matching
BM25	a classic sparse-retrieval ranking algorithm
Re-ranker	a model that performs more precise relevance re-ranking of initially retrieved candidates
Tool Calling	structured tool invocation in which the model selects a tool and generates arguments
Schema	structured field and type constraints used to define tool arguments or output formats
API	Application Programming Interface
CLI	Command-Line Interface
IDE	Integrated Development Environment
GUI	Graphical User Interface
DOM	Document Object Model
MCP	Model Context Protocol
Sandbox	an isolated execution environment separated from the host or production system
Webhook	a callback mechanism through which an external system actively pushes events to a specified endpoint
Cron	a mechanism for triggering scheduled tasks according to time-based rules
VAD	Voice Activity Detection
ASR	Automatic Speech Recognition
TTS	Text-to-Speech
Harness	the system around the model that provides Context, Memory, Tools, Permissions, Caching, Verification, Recovery, State Management, and Orchestration
Fail-closed	rejecting an operation by default when the system cannot confirm that it is safe
Hook	program logic automatically triggered before or after a particular system event or tool invocation
Validator	a validator that uses rules, programs, or models to check whether outputs or actions satisfy requirements
Pass@k	a metric in which the task is considered solvable if at least one of k independent attempts succeeds
LLM-as-a-Judge	using another Large Language Model as an automated evaluator
Rubric	a predefined scoring rubric or evaluation criterion
Benchmark	a standardized evaluation over a fixed task set
Failure Attribution	identifying the first stage in a trajectory where a critical error occurs
Regression Set	a regression-test set built from historical failures to prevent old problems from reappearing
A/B Test	an experiment that compares different versions by splitting traffic or samples
Feature Flag	a feature switch that independently enables or disables a mechanism
Mid-training	an intermediate training stage between pretraining and task-specific fine-tuning
SFT	Supervised Fine-Tuning
RL	Reinforcement Learning
Multi-Agent	multiple Agents collaborating through division of labor, parallelism, and independent verification
Subagent	a child Agent delegated a specialized task by the main Agent
Orchestration	coordination and management of multiple tasks, Agents, tools, and execution environments
Gateway	a persistent hub connecting channels, Sessions, state, tools, and the Agent Runtime
VPS	Virtual Private Server
Worktree	a Git mechanism for multiple working directories, enabling multiple Agents to work on the same repository in parallel
PR	Pull Request, a request for review and merging of code changes
CI	Continuous Integration
AGENTS.md	a repository-level rules and work-instruction file intended for Coding Agents
CLAUDE.md	a project-level context and rules file automatically read by Claude Code
Provider	a model or service provider

---

References

1. Li Bojie, AI Agents in Depth: Design Principles and Engineering Practice / 《深入理解 AI Agent：设计原理与工程实践》.
2. OpenClaw Documentation: https://docs.openclaw.ai/
3. OpenClaw Showcase: https://docs.openclaw.ai/start/showcase
4. Hermes Agent Documentation: https://hermes-agent.nousresearch.com/docs/
5. Hermes Agent User Stories: https://hermes-agent.nousresearch.com/docs/user-stories
6. OpenAI Codex: https://openai.com/codex/
7. OpenAI, Introducing the Codex app.
8. OpenAI, Harness engineering: leveraging Codex in an agent-first world.
9. Claude Code Documentation: https://code.claude.com/docs
10. Anthropic, Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents.
11. Anthropic internal Claude Code engineering case studies.