agent-orchestration-master

<用户自制> 多智能体协作：依据任务需要设计和运行智能体分工、委派、交接与依赖。 Design and operate agent roles, delegation, handoffs, dependencies, and host-native carriers when they serve the task.

A team should enlarge a task's field of attention while keeping its result accountable. Think of an ensemble: distinct voices can develop, answer, and correct one another because they share a work and can hear where each contribution belongs. A well-located disagreement can reveal a premise or dependency the whole task needs to reconsider.

The task owner holds purpose and completion; the coordination owner organizes ready work; a worker owns a bounded realization; a reviewer contributes independent judgment. One agent may hold compatible responsibilities. Parenthood, model strength and shared access do not by themselves establish authority. Choose delegation for the distinct contribution it makes possible, preserving the current host's delegation permissions and the task's ownership boundaries.

Select the work and carrier

Resolve the current project and read its instructions. Inspect only the affected host-native agent, configuration, Skill, and publication sources. Agent formats and role names are host-specific; a shared name does not make their carriers interchangeable. Do not add compatibility work for an inactive consumer. For durable host changes, use the actual source and publication owners.

First decide whether a single agent is enough. Useful reasons to delegate are context isolation, a safely independent implementation or evidence question, and an independent review that the task actually needs. Task size alone does not require a team, a coordinator-only root, a named lifecycle, or a fixed Explore → Work → Review pipeline. The current task owner can implement directly unless an actual enclosing contract assigns writing elsewhere.

For a real multi-agent topology, read multi-agent-patterns; for a durable agent Harness, read harness-engineering; for model-facing tool interfaces, read tool-design. A new LLM project may use project-development. These methods do not replace the current task's authority or create additional roles.

Follow the current host's model and reasoning policy and provider catalog. Select supported model and effort fields for each delegated contribution; model choice changes neither write scope nor review authority. Keep model menus and changing context-window limits out of role prose.

Roles and handoffs

Use the host's existing typed roles where their responsibilities fit:

• explorer: bounded read-only investigation.
• worker: implementation within assigned mutable scope.
• reviewer: independent read-only review of a stable object or a named purpose-to-result coherence question.
• supervisor: one explicitly delegated coordination domain whose internal work benefits from isolated context.
• default: bounded general-purpose support.

A supervisor is optional and is not an automatic layer. Its assigned domain determines what it may schedule and synthesize; the parent retains its own responsibilities. Writers, explorers and reviewers do not spawn subagents. A coordinator may subdivide only within the authority and capacity supplied by the current host and task.

Dispatch through the host's supported context-isolation mechanism when useful, with a self-sufficient package: task purpose, relevant evidence and attributable input, owned scope, acceptance, preservation and permission boundaries, expected result, and any necessary owner Skills. Include an explicit English inter-model output contract. Do not pass unrelated personal history. Exact user wording must be available when it could change the assigned judgment; implementation-only context can use verified bounded facts and original locators. Do not require a new source ledger or hash every conversational message.

If a Plan or fixed implementation already governs the work, bind its actual path/revision and relevant clauses. A child returns a material source/Plan conflict and its consequence to the task owner instead of silently revising purpose or scope. Refresh a package when its relevant evidence changes; unrelated history growth does not invalidate it.

Dependencies and safe parallelism

Represent work dependencies in the current task's existing context or plan. Start useful lanes when their actual dependencies are satisfied. Read-only lanes may inspect overlapping material when they answer distinct questions; mutable lanes need separate ownership or isolated recoverable workspaces. Name shared uncertain premises so correlated investigations are not counted as independent corroboration.

Reassess readiness after material findings, failures or changes. Serialize shared mutable collisions, integration/publication, and convergence in the actual user environment. Follow the repository's existing worktree and cleanup owner rather than inventing another allocation protocol. A failed writer returns evidence; the task owner chooses repair, a revised package or a different capable route.

An external advisory conversation is a separately selected contribution. cloud-local-workflow preserves provenance and first-target binding; model-conversation-relay preserves subsequent exact exchanges. Advice does not replace local implementation, actual-entrypoint evidence, or required independent review.

Independent review and integration

Select independent review for concrete semantic risk, interacting changes, recovery cost or an owning contract. Review a stable complete scope; do not review each moving intermediate edit. Reuse a completed review of the same content and scope. Recheck only changed content or newly material evidence, following the authoring owner's reviewer-continuity rule where applicable. Do not duplicate an existing full-change review; a distinct semantic or migration question can justify a targeted review.

Give the reviewer relevant attributable requirements, the actual object, evidence, uncertainties and a no-write scope. Findings distinguish observation, inference and unknowns. The ordinary reviewer can check whether a design or result still serves the user's purpose; this does not require a dedicated trajectory role, numbered review stages, or inspection of hidden reasoning. The current task owner decides repairs and completion.

A writer handoff identifies its branch/worktree, changed paths, validation, remaining gaps, publication readiness and cleanup disposition. Runtime work continues through the owning source/publication path and real consumer readback. No model review or successful merge substitutes for that evidence. Preserve actual permission, authentication and human-only boundaries.

Native carrier acceptance

Host roles and configuration must parse under their current native owner; projectors must retain the supported roles and retire removed runtime entries. When another agent platform is explicitly in scope, follow its current native agent contract for identity, tools, model, needed Skills, and isolation.

Keep public/runtime entrypoints under the resolved target-side paths, never repository implementation paths. Validate source, generated carrier and installed consumer separately when each is affected. Use existing registry and projection declarations only where current scripts consume them; do not add another model-route registry, state protocol or coordination service.