GitHub user alnzng added a comment to the discussion: [Feature] Sub-agent
Resource for Flink Agents - Framework part
Thanks for the detailed write-up and for laying out the options so clearly
@pltbkd . Before going into the concrete call API, I'd like to step back and
align on the high level scope first.
One thing I noticed: the A/B/C options mainly matter in one kind of design,
where the user calls a sub-agent directly in the action code and the method on
Subagent is the public API. If instead the framework orchestrates the
sub-agents and the user never writes these calls directly, then Subagent and
asAsyncCallable are internal, and their naming or shape matters much less. So I
feel it might help to confirm the user facing model first.
I can see two possible models, please correct me if I'm misunderstanding:
- Composite orchestration: the user declares "run A then B" or "run A, B, C in
parallel and merge", and the framework does the fan out and fan in. Here
Subagent is internal plumbing.
- Imperative invocation: inside an action the user writes
`ctx.getResource("reviewer", AGENT).call(prompt)` directly. Here the method on
Subagent is the public API, so its shape matters more.
>From PR #938 my impression is that the target is the imperative model, but I
>may be wrong, so it would be great if you could confirm.
If we are in the imperative model, I think the v1 scope may already answer most
of A/B/C. For v1 we want to support two scenarios, and both always return the
full result:
- Sequential: call sub-agents one by one, each call blocks until it returns.
This looks like a blocking call, basically Option A at N=1.
- Parallel: fan out several sub-agents, then fan in the results. This looks
like a callAll(...) over durableExecuteAllAsync, where the framework builds the
callables and yields once.
In both cases, I don't think we ever need a single call to stay in flight while
the action keeps doing other work. Option C (submit, get a handle, then poll)
seems mainly useful for that in flight case, so it may be out of v1 scope for
now.
So my feeling is that we might not need to choose between A/B/C yet. call plus
callAll could cover both scenarios, while asAsyncCallable / DurableCallable
stay as the internal mechanism rather than the caller facing API. I think this
also aligns with the "unintuitive" concern you raised, since the caller only
expresses intent (call or callAll). Please let me know if I'm missing something
here.
Would you mind sharing the high level concept first, and maybe pinning it here
or in the PR description, mainly which model v1 is committing to? Once that's
settled, I think the method level discussion will become much more concrete.
GitHub link:
https://github.com/apache/flink-agents/discussions/909#discussioncomment-17911555
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
