ACP: a delegated sub-agent cannot be addressed on its own

Ouverte
#595 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
api, cli

Piste de recherche

Start by locating the ACP JSON-RPC handlers for mcode/session/delegation/stop, mcode/session/steer, and the standard session methods; the issue gives no file paths or test names. Trace how those handlers resolve attached sessions and how the runtime addresses delegated sessions. Done means a client can message, stop, and read a child session independently, and unsupported stop targets return an explicit error while root tree behavior remains unchanged.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Product or interface

CLI - ACP

Use case and problem

A delegated sub-agent of a session is a full runtime session with its own session id, and the
runtime can address it on its own. The ACP surface does not expose that: every extension
accepts only the id of a session that is attached to the connection, and the delegation
methods work on the whole tree.

So a client that speaks ACP can watch the tree of delegated tasks, but it cannot do what the
app itself does: talk to one delegated task, open it, or stop it without stopping its parent.

Measured against mcode 0.7.3 over raw JSON-RPC on stdio, with a child session that was
running (the parent had delegated a background task):

mcode/session/delegation/get      {sessionId: <child>}  -> -32002 Resource not found: <child>
mcode/session/delegation/stop    {sessionId: <child>}  -> -32002 Resource not found: <child>
mcode/session/steer              {sessionId: <child>}  -> -32002 Resource not found: <child>
mcode/session/queue/list         {sessionId: <child>}  -> -32002 Resource not found: <child>
mcode/session/goal/get           {sessionId: <child>}  -> -32002 Resource not found: <child>
mcode/session/activate           {sessionId: <child>}  -> -32002 Resource not found: <child>
session/prompt                   {sessionId: <child>}  -> -32002 Resource not found: <child>
session/resume                   {sessionId: <child>}  -> -32602 Sub-agent Sessions are internal and cannot be opened.
session/load                     {sessionId: <child>}  -> -32602 Sub-agent Sessions are internal and cannot be opened.
session/fork                     {sessionId: <child>}  -> -32602 Sub-agent Sessions are internal and cannot be opened.
session/cancel                   {sessionId: <child>}  -> ignored without a reply; the child was still running after 6 s

The tree is visible from the parent (mcode/session/delegation/get returns the members with
their own session ids and statuses), and a delegated task also announces its session id in the
tool call output (sub_session_id). What is missing is any way to act on one of them.

One detail worth flagging: mcode/session/delegation/stop accepts unknown fields and ignores
them. A call that names a target is answered with a receipt for the whole tree:

mcode/session/delegation/stop {sessionId: <root>, targetSessionId: <child>, childSessionId: <child>}
-> {"rootSessionId":"<root>","rootStopped":true,"stoppedSessionIds":["<child>"],
   "activeSessionIds":[],"failedSessionIds":[]}

A client that reads that receipt as "the named task was stopped" will be wrong: the whole
tree was stopped instead, and the receipt does not say which member it stopped.

Desired behavior

Four contract points, in order of how much they unlock.

  1. Address a delegated task. A way to send a message to one delegated task and to receive
    its answer, addressed by its session id (the id is already known to the client — the tree
    and the tool call output carry it). The same shape as mcode/session/steer, but with a
    child as the target.
  2. Stop one delegated task. Stopping a delegated task must not stop its parent: the
    parent may still be waiting for the answer, and the point of the delegated task is that it
    can end on its own. The runtime already distinguishes the two.
  3. Read the transcript of a delegated task. Read-only access to what the delegated task
    did and said. Without it there is nothing to show in a panel opened for that task.
  4. Do not silently ignore what a call says. If a method receives a target it does not
    support, it should say so rather than answer for a different target.
Acceptance criteria
  • A client can send a message to a running delegated task and gets its answer, without the
    parent's turn being affected.
  • A client can stop one delegated task; the parent session stays usable and its own turn is
    not cancelled by that call.
  • A client can read the transcript of a delegated task in a read-only manner.
  • mcode/session/delegation/stop either stops what the caller named, or rejects a target it
    cannot honour with an explicit error. Silently stopping the whole tree and reporting a
    receipt is not acceptable.
  • The existing behaviour of the tree methods is unchanged: delegation/get still answers for
    the root, delegation/stop still stops the tree.
Platform

Multiple platforms

Alternatives and additional context
  • A separate method per action (delegation/message, delegation/stop_child, delegation/attach)
    is fine as long as the target is explicit and the answer says which task it acted on.
  • The desktop app already shows delegated tasks as an agent team and can stop one of them; the
    client side of this problem is tracked in the Paseo repository:
    https://github.com/getpaseo/paseo/issues/8300 — it tracks the client side, but a client cannot
    stop one delegated task over ACP while the methods above do not exist.
  • This request is about the ACP surface for delegated tasks. The queue of messages for a
    session is a separate concern and is tracked separately.
Langage dominant
TypeScript
Étoiles
2.2k
Forks
281
Merge moyen
12 h 51 min
PR mergées (30 j)
34

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MiniMax-AI/minimax-code

Toutes les issues de MiniMax-AI/minimax-code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.