refactor(agent-core-v2): extract swarm into a scope-organized feature - #2874
Conversation
|
commit: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 817231acd6
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| this.contributeService(LifecycleScope.Session, ISessionSwarmService, SessionSwarmService, { | ||
| activation: ScopeActivation.OnScopeCreated, | ||
| }); | ||
| this.contributeTool(IAgentSwarmTool, AgentSwarmTool, { name: 'AgentSwarm', domain: 'swarm' }); |
There was a problem hiding this comment.
Keep AgentSwarm in the static tool universe
When AgentSwarm is contributed only through the feature record, it no longer appears in getAgentToolContributions(). SubagentTool.knownToolReferences() still uses that static table plus the caller agent's active registry to describe other subagent profiles; so if the current caller profile does not activate AgentSwarm (for example coder) and any workspace/session/global tool restriction makes buildProfileDescriptions() take its effectiveTools branch, the advertised tools for the agent subagent profile omit AgentSwarm even though spawned agents can still use it. Please keep a static descriptor entry for AgentSwarm or teach those descriptor-only readers to include feature-contributed tools.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in fbaf603. SubagentTool.knownToolReferences() now reads the full AgentToolContribution collection (static registrations and feature-contributed tools alike) instead of the static contribution table, so the per-profile tool listings keep advertising feature-contributed tools such as AgentSwarm even when the caller profile does not activate them and a workspace/session restriction forces explicit enumeration. Added a regression test covering exactly that case (caller profile without AgentSwarm + global tool restriction).
c8c32ba to
714dafc
Compare
- move src/agent/swarm, src/session/swarm, and src/agent/tools/agent-swarm
into src/features/swarm/{agent,session,tools/agent-swarm}; swarmOps.ts
stays a static import=register wire channel at the feature root
- add SwarmFeature carrying the three runtime registrations
(IAgentSwarmService, ISessionSwarmService, IAgentSwarmTool) with
ScopeActivation.OnScopeCreated preserved
- switch src/index.ts to precise leaf exports and update import sites,
including the kap-server and kimi-inspect deep-path imports
- move tests to test/features/swarm and re-assert service overrides in
the test harness so stubs keep winning over feature contributions
…riptions SubagentTool.knownToolReferences() now reads the full AgentToolContribution collection (static registrations and feature contributions alike) instead of the static contribution table. A caller profile that does not activate a feature-contributed tool (e.g. AgentSwarm) no longer drops it from the per-profile tool listings the description advertises for spawned profiles when a workspace/session restriction forces explicit enumeration. Add a regression test with a caller profile lacking AgentSwarm under a global tool restriction.
- add sessionProfile.ts/sessionAgentConfig.ts route helpers that resume the session and dispatch title/metadata and the agent_config patch to the native v2 services directly - drop updateProfile from ISessionLegacyService, leaving only the status rollup and the goal read in the legacy adapter - wire shape and client-visible behavior unchanged
714dafc to
e74248b
Compare
Related Issue
No linked issue — internal structural refactor; see Problem below.
Problem
In
agent-core-v2, the swarm capability is scattered across three directories —src/agent/swarm/(swarm mode),src/session/swarm/(batch scheduling), andsrc/agent/tools/agent-swarm/(AgentSwarm tool) — each self-registering through staticregisterScopedService/registerAgentToolServiceside effects. The repo has standardized on self-contained Feature units (registerFeature+IFeatureAssemblyService, seepackages/agent-core-v2/docs/features.md;planwas the first port), and swarm should follow the same mechanism so features are added, removed, and assembled uniformly.What changed
Pure structural move — zero runtime behavior change:
src/features/swarm/{agent,session,tools/agent-swarm}. NewswarmFeature.ts(SwarmFeature extends Feature, module-levelregisterFeature) carries the three runtime registrations (IAgentSwarmService,ISessionSwarmService,IAgentSwarmTool) viacontribute*, preservingScopeActivation.OnScopeCreated— the services subscribe toturn.ended/onBeforeExecuteToolin their constructors, so lazy activation would be a behavior change.swarmOps.ts(wire vocabularySwarmModel,swarm_mode.enter/swarm_mode.exit) stays a static import=register channel, hoisted to the feature root perdocs/features.md. Wire keys are unchanged, so session persistence/replay stays compatible.src/index.tsswitches to precise leaf exports for the new paths (no barrel); import sites updated (sessionLegacyService,core-api, plus the deep-path imports inkap-serverevents-zod.tsandkimi-inspectpanels.ts).test/features/swarm/with import-path updates only. The test harness now re-asserts feature-contributed service overrides after scope creation so seeded stubs keep winning over feature contributions (previously guaranteed by static registration's skip-when-seeded semantics).Verified:
pnpm --filter @moonshot-ai/agent-core-v2 test(312 files / 4956 tests pass),pnpm --filter @moonshot-ai/kap-server build,pnpm --filter @moonshot-ai/agent-core-v2 lint:imports, and the wire/state/config manifest generation all pass; the regenerated wire manifest shows only the expected path-comment changes.Checklist
gen-changesetsskill, or this PR needs no changeset. (no changeset: internal refactor with no published behavior change; theplanfeature port shipped without one either)gen-docsskill, or this PR needs no doc update.