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

Abierto
  • ¿Algo no está bien?
#595 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
2.2k
Forks
281
Merge medio
12 h 51 min
PR fusionados (30 d)
34

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MiniMax-AI/minimax-code

Todos los issues de MiniMax-AI/minimax-code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.