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

Aberta
  • Algo errado?
#595 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
api, cli

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
TypeScript
Estrelas
2.2k
Forks
281
Merge médio
12h 51min
PRs com merge (30d)
34

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de MiniMax-AI/minimax-code

Todas as issues de MiniMax-AI/minimax-code

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.