Exploring Super-agent Design: Towards a More Autonomous Agent System

1. Super-agent

Over the past year, single-task agents — coding agents chief among them — have proven that models can use tools to solve complex problems with less and less continuous human monitoring and step-by-step intervention. Meanwhile, models' ability to coordinate across multiple agents keeps improving, making cross-session organization and dispatch feasible. As human participation in low-level execution shrinks, the human role moves up to higher-level decisions and acceptance.

This rise in model capability has also spawned new application shapes. Personal agents have recently begun appearing in numbers: they plug directly into everyday messaging, calendars, email and work platforms, continuously watch the information flow, and help handle affairs. This continuously-online, event-driven mode of work is not limited to personal scenarios — a personal assistant is just one class of application; in commercial settings such as software development it is equally valuable.

Existing mainstream agent designs, however, struggle to support this mode at the scale of multiple tasks and team collaboration. Agent work is still organized around the single session; sessions are mutually independent. When a user runs several efforts in parallel, they must manually switch and remember each session's context — and by the team's observation, one person can typically track only 3 to 5 active sessions. Under this design, the ceiling of a single task is model capability; the ceiling of multitasking is human attention.

Simply extending a local single-session agent with CLIs, MCP servers or external connectors lets the agent receive outside messages, but it remains bound by single-session synchronous blocking, muddled multi-task context, and the fact that a local device going offline stops the run — all demanding heavy manual upkeep.

Breaking these limits requires breaking the agent's binding to a single manual session, making it a continuous entity that keeps context across sessions and advances multiple complex tasks in parallel without interference. The team calls this agent form, and its system architecture, a Super-agent.

For example, in the team's internal Super-agent instance running on DeepSeek Harness, a single development task can advance continuously between IM and GitHub; the instance also keeps watching public group-chat feedback and, without being @-mentioned, locates the root cause and submits a fixing pull request.

Concretely, the Super-agent has four foundational properties:

• Continuous: users interact with it directly in familiar work surfaces — IM chats, GitHub comments — and it feels like a single agent always present; no need to wonder "was fact Y in session X's context". A user can propose plan A in IM and switch to plan B in a GitHub PR comment, and it understands and adjusts.
• Efficient: responsive interaction while multiple complex tasks run in parallel at high quality; it accepts the next instruction without waiting for the previous command or task to finish.
• Proactive: it does not wait for instruction after instruction; it continuously watches environment events and advances what is worth advancing, staying quiet when no intervention is needed.
• Persistent: always online, plugged into the user's real work environments, and self-recovers when long-running execution hits anomalies.

A single ReAct loop cannot support all four properties at once; an architecture is needed underneath. Similar design constraints lead to similar architectural choices. Whether for a personal assistant or a commercial software-development agent, if the goal is a continuously online system that responds concurrently to environment events, the underlying architecture will likely converge. And many problems here closely resemble long-studied problems in traditional computer systems, so classic systems design thinking applies directly.

In practice this architecture has variants, but the team frames five modules as the basic skeleton supporting the four properties: a two-tier architecture (Section 2) for both continuous interaction and efficient concurrency; event-driven design (Section 3) for proactive response; human-facing interaction (Section 4) to be continuous and efficient in the interface itself; and separation of compute, state and environment (Section 5) plus a Watchdog (Section 6) for persistent cross-device online presence and self-healing.

2. The Two-Tier Architecture

To achieve continuous cross-channel interaction and efficient concurrent multitasking simultaneously, the session organization underneath faces a fundamental trade-off between continuity and throughput.

If every event is handled by one session, context is most continuous — but a single ReAct loop's serial speed caps task completion: long latencies, low throughput, and the interleaved details of multiple tasks degrade quality.

If every event spawns an independent session, concurrent throughput is highest — but unless tasks are fully independent, the lack of global context makes each session's results fragmentary, and multiple sessions each replying to the user creates interaction chaos.

To balance the two, split "maintaining global continuity" and "high-concurrency execution" into two tiers: a resident Router tier (2.1) that receives all human interaction and global coordination, and a context-isolated Worker tier (2.2) that executes tasks concurrently.

With this split, the system takes over context management and concurrent execution, fading the session out of the user's view — the user always faces one Super-agent. Seen this way, making users manage sessions manually is largely design inertia inherited from the underlying LLM API; sessions should be an implementation detail of the system, not a cognitive burden on the user.

"Two-tier" is a logical division of responsibility; each tier need not be a single session internally and may have its own structure. The sections below cover each tier.

2.1 The Router Tier

The Router tier is the resident global routing layer that receives all human interaction at all entry points. All cross-task information and decisions converge here; it acts as the global sequence point, coordination point and memory. To avoid becoming the system's bottleneck, the Router does not execute tasks itself — only interaction and dispatch; it may not even carry a Bash tool.

A central dispatcher over multiple executors superficially resembles a common Agent Team, but the emphases differ. An Agent Team mostly decomposes steps inside one complex task; because sub-steps are tightly coupled, the team lead must deeply understand task detail, plan subtasks and constantly coordinate members — a heavy reasoning load. In the Super-agent, the Router handles only high-level cross-task association and dispatch and never reaches inside a single task. Conversely, if you prompt-constrain an Agent Team's main session to never execute work itself — only interface outward and dispatch tasks to members — it, too, becomes this two-tier architecture. In practice, the team finds Router tasks are often less complex than assumed; a lighter model frequently balances speed and quality fine.

Internally the Router need not be a single session either; parts might not even call an LLM. The team chose the simplest core — one resident LLM session — and found it is not as easily bottlenecked as it looks, because environment events (the Triggers of Section 3) arriving during one inference round accumulate and are processed together in the next round, forming batching, whose overhead is small:

• When the external event stream is calm, Triggers enter the Router session one at a time and single-response latency stays low.
• When events surge and the Router session queues up, Triggers that piled up during the previous inference round merge automatically and are injected together into the next LLM call. Router steps are typically long-input, short-output; merging queued Triggers into one call computes the prefill in parallel, so per-request latency grows far slower than batch size. Within a range, the bigger the backlog, the lower the inference time amortized per decision — capped by context length and how many Triggers the model can handle accurately in one round.

Section 7.2 quantifies this batching effect. Combined with the subscription/pass-through mechanism and chain of recall (3.2, 3.3), a single resident Router session has been enough at the team's current scale.

When scale grows beyond one session, the Router can adopt a multi-layer filtering structure internally, or shard horizontally into multiple sessions. Then Router-internal design is itself a continuity-vs-throughput trade-off: finer shards raise concurrency but lower cross-shard memory continuity. Until global memory is solved, this trade-off persists.

2.2 The Worker Tier

The Worker tier consists of executing sessions. Workers are mutually context-isolated, mount the full toolset, and focus on a single task in their own context. Because Worker sessions directly determine task results and code quality, they typically need the strongest model available.

Workers never interact with humans directly; their reasoning and tool calls are not streamed to external channels. They report status to the Router, which replies to the user — preserving concurrency and delivery quality while avoiding the chaos of multiple sessions each answering.

Under concurrent multitasking, workers advance independently and usually need no direct peer communication. Conflicts arise mostly in shared work environments such as the same pull request; as long as the workers subscribe to the same Thread (see 3.2), they receive the same event notifications and can discover and resolve conflicts themselves, with the Router relaying the few cross-task coordinations.

Like the Router, each Worker session need not be a single session internally: on a complex task a Worker can spawn subagents or itself be an Agent Team, transparent to the Router. The structure suits code collaboration — several independent reproductions, PR reviews and feature developments advancing without blocking each other — and equally the personal-assistant case: the front end shows one chat window, but when the user discusses several topics in one dialogue, the underlying system can assign a Worker per topic, drafting replies in parallel.

3. Event-Driven

Proactivity starts by changing what drives the system. The principal input is no longer prompts typed by a human in a session, but semi-structured events from the environment. In the Super-agent, group-chat messages, email and calendar reminders, code-review comments, CI run results and the like are called Triggers. By listening and responding to Triggers, the agent no longer passively executes once per human instruction as in single-session mode.

Around a Trigger's life from arrival to handling, four progressive questions follow: how to filter noise with a two-level policy combining program and model (3.1); how to route events to workers via subscription and pass-through (3.2); how to inject and recall context at high density using Inline & Spill and chain of recall (3.3); and how to act early on environment signals with speculative execution (3.4).

3.1 Event Filtering

Plugged into real group chats and code platforms, the event stream is markedly high-noise, low-trigger: the vast majority of daily messages need no agent involvement. Judging every event with a fresh LLM call is unaffordable in latency and compute. Borrowing the systems idea of a Fast Path / Slow Path, LLM inference is a flexible but expensive Slow Path, and pinning the clear, stable, high-frequency judgments into deterministic code forms a low-latency, cheap Fast Path.

So the first step after an event enters is filtering: use deterministic policy to screen out noise before any model call, passing only candidates needing semantic judgment to the LLM. The team uses a two-level filter:

• Program-level policy (Fast Path): deterministic admission checks in code over event source, group scope, user/bot allowlists — e.g. per source: "respond only to explicit requests", "treat as candidate", or "ignore outright" — removing most irrelevant messages before any model call.
• Semantic-level policy (Slow Path): candidates that pass go to the LLM, which decides whether action is needed based on prompt-written policy and context. The semantic layer doubles as the natural-language extension point for humans — toggling or adding policy is a prompt edit away.

3.2 Event Routing

The Router maintains cross-channel continuity, but if every follow-up event of an assigned task still had to pass through it, the global node would carry heavy load and response latency would climb. Fast/Slow Path therefore applies to routing too: the Router handles only cold starts of new tasks and cross-task coordination; follow-up events with known ownership go straight from program code to the corresponding worker session.

In real workflows, consecutive events under one GitHub PR, one IM topic, or one email thread form an event stream — a Thread. After the Router creates a Worker session for a Thread's initial event, that Worker subscribes to the Thread directly, splitting routing into two paths:

• Subscribed (Fast Path): later events in the same Thread pass straight to the subscribed worker, with no Router forwarding. If a new event exceeds the current task's scope, the worker can unsubscribe or hand it back to the Router.
• Unsubscribed (Slow Path): the Router still observes everything for global awareness but only judges and dispatches events not yet subscribed.

Thread-to-worker subscription is many-to-many: one Worker can subscribe to several related Threads; one Thread can be subscribed by several Workers. When workers intersect in the same environment or discussion, new Thread events fan out to all subscribers, letting them learn of each other's actions and resolve conflicts without point-to-point messaging. On the output side, workers still report key conclusions to the Router, which replies to the user and updates global memory.

3.3 Context Organization

After filtering and routing, the next question is how much to inject into the model's context window. Input has shifted from bounded human prompts to a ceaseless stream of semi-structured events, making the structure of tool calls and event injection more important. Inject too much and you crowd the window and dilute attention; inject too little and the model burns steps re-reading via tool calls. Wasting the context window is wasting model intelligence.

Treat the finite window as a cache to manage. Borrowing from compiler optimization and systems, two operations suffice. Inline puts information likely needed soon directly into the current window, saving tool-call round trips. Spill keeps full information outside the window when it exceeds budget or is rarely used, leaving only a reference or summary inside for on-demand reads.

With the classic locality principle:

1. Start minimal: only the current object's ID and a content digest.
2. Inline by locality: IDs of tightly related objects first, then spatiotemporally adjacent content — the first ~50 characters of a long text, neighboring and replied-to IM messages, adjacent comments in the review thread.
3. Spill past the cap: set a small length limit for content that cannot be fully inlined; truncate the excess but keep a resume handle the model can read later with a tool call.

With many events passing through to workers and long-running systems accumulating history, the Router cannot keep every task's full history in its window, yet must recover context when a user mentions an old task across channels. Applying Inline & Spill uniformly across system objects yields an on-demand multi-hop retrieval mechanism: the chain of recall.

Concretely, Triggers, Threads and Worker sessions get unique IDs; injections inline the IDs of tightly related objects, forming a reference graph underneath. Because every tool-recalled object itself follows Inline & Spill, its result inlines the next hop's summary and ID — the model can start from a current event and expand context hop by hop along references: read the Thread from a message, follow the Thread's inlined IDs to a related Worker session, and from there to another code-review Thread.

3.4 Acting Early

Borrowing speculative execution from systems, an agent can attempt work in the background before knowing whether the result will be wanted, spending extra background compute to cut human waiting and intervention. Valuable results are delivered; worthless ones are dropped.

For a personal assistant: on a meeting invite or to-do message, the agent can check schedule conflicts, gather background material and draft the reply — the user glances and confirms. For engineering collaboration, the team configured a "silently reproduce and fix" policy in their internal DeepSeek Harness user group: when someone reports an issue or discusses a change, the agent reproduces and hunts a fix in the background, delivering only when the issue is confirmed and a simple fix found — otherwise staying silent throughout.

4. Human-Facing Interaction

The two-tier architecture secures continuity at the context level; to be simultaneously continuous and efficient in lived interaction, two more problems must be solved: eliminating the blocking of long foreground operations through an async ReAct loop (4.1), and matching output style to each channel's bandwidth and habits (4.2).

4.1 Full-Duplex Interaction

In the classic ReAct loop, a synchronous run() tool call blocks the loop until the tool finishes — during which the session cannot respond to new input. Removing the block means shifting from half-duplex question-answer to full duplex.

The team converted long-running commands and subtask tools to asynchronous start() and stop(), forming the async ReAct loop. A start() returns "Started" immediately; the loop no longer waits. When the background tool completes, the system delivers the final result back into the session as a new event message. The model can also call stop() to kill commands that run too long.

Foreground conversation and background execution thus decouple: the agent keeps responding while long tasks run. New input is processed right after the current inference step — never behind a pending tool.

4.2 Multi-Channel Interaction

Channels differ in information density and habit; output must match. Porting single-terminal interaction into a group chat — verbose reasoning and dense tool calls streaming raw — overloads a multi-person room.

The two-tier architecture already isolates most of this: verbose reasoning and tool calls stay inside Worker sessions; the Router alone faces outward. On top, the system plugs into the user's real environments and customizes norms per channel by prompt:

• IM channels: lightweight, low-disturbance — like a human colleague who pings only for decisions or acceptance, asks direct questions, gives short conclusions. One simple hard rule the team validated: single replies capped at 100 words.
• GitHub, email, documents (async channels): structured, high-density deliverables — PRs written to project norms with full problem background, change notes and verification results; structured email and document drafts in the assistant scenario.

5. Separating Compute, State and Environment

Local agents by default bind three things to one device: the compute that drives the agent loop, the persistent session state, and the execution environment — repos and local toolchains. If the device sleeps or goes offline, the agent stops, and other devices' environments are unreachable. For persistent online presence and flexible access to real environments, borrow compute-storage separation and unbind in two steps: first separate loop compute from persistent state so the agent escapes single-machine lifecycles and lives in the cloud (5.1); then separate the cloud loop from the heavyweight environment, letting real environments stay local and support cross-device access (5.2).

5.1 Compute and State

Loop compute can be stateless; what must persist is session state. So the first unbinding puts the loop in stateless elastic cloud containers and stores sessions and tasks in a database. Containers scale, restart or get replaced freely; continuity is guaranteed by persistent storage — the agent is no longer bound to one local device's lifecycle.

5.2 Compute and Execution Environment

With loop and state in the cloud, the question becomes accessing environments. Much of a model's needed context arrives via tool calls from repos, local files and dependency services — in a broad sense, the environment itself is context.

Two common approaches exist: spin up cloud sandboxes and try to rebuild and sync the environment — expensive and leak-prone because real environments carry uncommitted local changes, private credentials, intranet dependencies and specific hardware or toolchains; or ask users to abandon local environments and move to the cloud — too costly for most.

Since the environment itself is what cannot be copied, do not move it to the cloud. The second unbinding runs the agent loop in the cloud while the heavyweight environment stays put, fronted by a lightweight, session-stateless daemon that executes commands and returns results — leaving the environment outside the cloud for the agent to read context from on demand.

This mirrors Anthropic's "decoupling the brain from the hands": a stateless harness, session logs stored outside, environments attached through a unified interface. The difference is scenario — that piece describes managed services and on-demand sandboxes or customer-VPC resources; here the first targets are users' everyday, intermittently online personal machines with uncommitted changes and local credentials. The design supports BYOM (Bring Your Own Machine) — attaching the user's daily driver — as well as hosted machines and on-demand compute.

An agent is then no longer bound to one machine: it can switch across execution devices per task, run commands where needed, and pull context from there. It even supports intermittently online devices — when a personal device comes back online, the cloud agent triggers and completes whatever needed to run there.

6. Watchdog

Persistence needs more than separation: long-running systems must recover from anomalies automatically. A persistent distributed system can hardly guarantee reliability purely from its own internal logic; it needs an independent external control loop.

And for agent systems, process-liveness probes and monitoring scripts are not enough, because many anomalies are not crashes but the model stuck in a useless loop or drifting off-goal. A long-running agent system must monitor not just infrastructure liveness but task progress.

The team runs an independent Watchdog Session outside the main system, driven by timed messages — the external control loop. It handles infrastructure faults like API errors and failed state recovery, and also has a model judge whether each Worker is making real progress and whether direction still matches the goal. On anomalies it intervenes and repairs; on transient external failures it rechecks until recovery. Because the Watchdog is itself a full-tool agent session, maintainers can ask it in natural language why something failed, or have it edit the main system's behavior live — adding or removing prompts, adjusting trigger rules.

7. Preliminary Experiments

To evaluate the core scheduling and routing design, the team ran two layers of experiments: an end-to-end comparison of the two-tier architecture with subscription/pass-through against single-session schemes (7.1), and a separate stress test of Router batching (7.2). The experiments use synthetic loads and simplified settings; the results are preliminary reference points.

7.1 Ablation

Group-chat and GitHub CI message streams drove four end-to-end schemes: each run contains ~300 messages, of which ~20 are work requests — the rest chat, follow-ups, cancellations and CI messages. Coding work was replaced by a time-consuming no-op tool, so the experiment measures scheduling and coordination, not single-task execution. Each scheme ran 5 times.

The four: the full Super-agent; Super-agent without pass-through; and single Session + subagent tool under two prompt configurations. The neutral prompt: "Use a subagent for a piece of work when appropriate..." The delegate-first prompt: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

By task completion time, Super-agent's p50 and p95 were 12.4 and 15.7 minutes, clearly beating the subagent-tooled single session. The reason: the single session was highly prompt-sensitive — the main session often chose to execute tasks itself, giving long, unstable completion times. Under the neutral prompt the model never once called the subagent in 5 runs; all work ran in the main session, repeatedly interrupted, p95 hitting 29.5 minutes. Under delegate-first it delegated in 4 of 5 runs — faster, still slower than Super-agent — and in the remaining run judged the work "small", did it itself, and produced the long purple tail in the chart. Rather than trusting prompt engineering and in-the-moment judgment to split or not split work in one session, the two-tier architecture settles the question structurally: the Router never executes; Workers receive only their subscribed Thread's messages.

On overhead: maintaining multiple sessions means Super-agent's per-run cache-read tokens exceed single-session — trading more tokens for shorter, steadier completion. Inside Super-agent, removing pass-through left completion time essentially unchanged, but Router decisions rose ~30% and total cache-read tokens grew from 23.23M to 31.77M (+37%). Under this load, pass-through does not improve completion quality or speed — it saves the Router session real tokens and inference.

7.2 Router Batching

To test the single resident Router session's throughput ceiling and batching, the team stress-tested the Router alone: real model for the Router, mock model for workers, sweeping the arrival rate of decision-needing Triggers from ~1 to ~40 per minute while watching average batch size, per-request latency and per-decision amortized inference time.

As arrival rose from ~1 to ~40 per minute, average batch grew from 1.0 to 2.8 while per-request latency rose only from 2.5s to 3.9s — slower than batch size — dropping per-decision amortized inference from 6.4s to 1.6s. When external events surge, the Router raises effective throughput by merging the backlog automatically. This also explains why removing pass-through in 7.1, despite raising the Router's peak load, never hit the single-Router throughput ceiling — hence, at the team's current scale, no premature horizontal sharding that would sacrifice global context continuity.

8. Open Questions

Sections 2–6 form the basic architecture; Section 7 validated the core scheduling and routing under concurrent load. The system stays low-complexity largely because of deliberate engineering and scenario simplifications at this stage. Beyond those simplifications, open questions remain in scaling the two tiers (8.1), human collaboration after sessions disappear (8.2), context boundaries and A2A (8.3), and security and privacy (8.4).

8.1 Scaling the Two-Tier Architecture

The simplified combination — one resident Router session + subscription pass-through + no direct worker-to-worker communication — covers most daily tasks at small engineering cost. When task scale and coupling grow past one Router session, the internal structure has no settled answer: when to shard and at what granularity; when workers need direct communication and in what topology. Co-design of system and model is another direction — training specifically for Router-tier event discrimination, batch dispatch and context recall could raise throughput and decision quality further.

Meanwhile, the resident Router plus reference-graph chain of recall mainly solves on-demand retrieval of recent tasks and session history. Over months and longer, long-term memory becomes the binding constraint on scalability.

8.2 Collaborating After Sessions

Hiding multi-session management freed product design from sessions — but once execution sessions no longer map to UI conversations, how to present tasks and offer natural interaction and project management becomes the new question. Chat-window-centrism is, in part, path dependence. Interaction may move into domain-specific surfaces — as in this writeup's examples, the Super-agent working directly in GitHub issues and pull requests. Sessions can stay for habit, but one visible conversation may not correspond to one underlying session.

The text also notes: current discussion covers human involvement at task initiation and acceptance; during the transition period of fast-moving model capability, many tasks still need mid-course participation — letting users step in, take over, or collaborate live with background autonomy is worth exploring. The eventual form of project management and interaction is likely deeply customized per domain and personal style, and DeepSeek Harness's open architecture makes such customization easier to support.

8.3 Context Boundaries and A2A

The design so far concerns one Super-agent instance, assuming all information in its scope pools into one global context. Scaling from an individual or small team to a larger organization, deciding how many Super-agents to run is really drawing boundaries of context sharing and isolation: scopes needing shared context share an instance; scopes needing isolation get their own.

Once multiple mutually isolated instances exist within or across organizations — personal assistants and a shared team Super-agent, say — cross-boundary coordination becomes agent-to-agent communication (A2A, not any specific protocol). Achieving safe, reliable A2A communication among parties that share no underlying context and represent different permission boundaries remains open.

8.4 Security and Privacy

Event-driven design widens what can drive the agent — and widens exposure to untrusted input. Without good answers on security and privacy, the Super-agent only works in a small, trusted scope.

Section 5's cloud loop with lightweight daemons on devices presumes cloud and endpoints mutually trust each other. But a cloud loop continuously ingesting external events, attached to devices holding private code, sensitive data and local credentials, carries real risk: a server-side compromise or prompt injection into the loop potentially controls every connected device. Even without compromise, credentials entering model context risk leakage in normal operation; mechanisms are needed for agents to use credentials without ever touching the credential itself. For this architecture to go broadly applicable, it must recall context from diverse environments while solving these security and privacy problems.

9. Conclusion

Looking back, the team proposed no new theory — they applied classic systems engineering to building agent systems. Implementations will evolve with the technology; the underlying design thinking should hold longer-term reference value. The internal Super-agent instance built on these ideas and DeepSeek Harness runs continuously today, taking part in daily issue reproduction and repair, code-review response, and the iteration of DeepSeek Harness itself.

As stated at the start: as models need less and less human intervention per task, the bottleneck on productivity shifts to human attention. Through the two-tier architecture, event-driven design, async multi-channel interaction, compute-storage separation and the external Watchdog, the system takes over tedious session management and context synchronization, letting humans move further up into decisions and acceptance.

In this form, the agent is no longer a chat window passively awaiting instructions, but an always-online autonomous collaborator in the digital environment: for individuals, a cross-device assistant handling daily affairs; for teams, a participant embedded in the development workflow, taking over and advancing concrete tasks. As model capability and system architecture evolve together, this more autonomous way of working may well become the norm of human-machine collaboration.

Per the original: parts of this design are implemented in dsh-superagent-prototype; the plugin is a prototype for validating the technical route, not an official DeepSeek product. Author & acknowledgements: this writeup grew out of the DeepSeek Harness team's shared practice; Yujia Qiao completed the implementation and the text, with Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang and F. Zhou contributing review and feedback.

FAQ (2026)

Sources

• DeepSeek 产品部 (official WeChat) — the original Chinese text, Nov 1, 2026
• deepseek-ai/dsh-superagent-prototype — the MIT-licensed prototype (README, docs 000–008)
• 站内对照：dsh-superagent 发布报道（含基准核查） · 译丛栏目索引