fix: 同步动态 skill tool 激活状态

[guslegend0510]

问题背景

Issue #1715 中，动态 skill 在两处会出现工具不可见的问题：

1. onSystemPrompt 阶段新注册或激活的 tool group 没有同步到当前 call state，导致首轮 reasoning 看不到动态工具。
2. load_skill_through_path 执行后，toolkit 中对应的 skill tool group 已经激活，但 ReActAgent 下一轮 reasoning 仍然读取旧的 state active groups，导致 skill-bound tools 仍不可见。

变更内容

1. 在 ReActAgent 中补充 toolkit active groups 到当前 call state 的同步时机：
   • consumeSystemMsgAfterPreCall(...) 后同步一次，保证首轮 reasoning 可见；
   • acting 阶段工具执行完成后再次同步，保证下一轮 reasoning 可见。
2. 在 harness 侧补齐 skill load 后的 tool group 激活逻辑：
   • SkillLoadTool 成功加载 skill 后，优先使用 param.getAgent().getToolkit()，否则 fallback 到 runtime 持有的 toolkit；
   • 如果存在 <skillId>_skill_tools，则立即激活对应 group。
3. 在 SkillRuntime.install(...) 中，每次安装时刷新 runtime 持有的 toolkit 引用。
4. 补充回归测试，覆盖：
   • onSystemPrompt 激活的 group 在首轮 reasoning 可见；
   • tool 执行后激活的 group 在下一轮 reasoning 可见；
   • harness 中 load skill 后会激活对应 skill tool group，且 toolkit fallback 引用会刷新。

验证

已执行并通过以下测试：

• mvn -pl agentscope-core '-Dtest=ReActAgentToolGroupSyncTest' '-Dsurefire.failIfNoSpecifiedTests=false' test
• mvn -pl agentscope-core '-Dtest=SkillRuntimeIntegrationTest,ReActAgentMiddlewareIntegrationTest' '-Dsurefire.failIfNoSpecifiedTests=false' test
• mvn -pl agentscope-harness -am '-Dtest=SkillRuntimeTest' '-Dsurefire.failIfNoSpecifiedTests=false' test
• mvn -pl agentscope-harness -am '-Dtest=SkillLoadToolFrontmatterViewTest' '-Dsurefire.failIfNoSpecifiedTests=false' test

[codecov]

Codecov Report

❌ Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ope/harness/agent/skill/runtime/SkillLoadTool.java	75.00%	2 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[AgentScopeJavaBot]

🤖 AI Review

This PR fixes a real and well-identified issue: dynamic skill tool groups activated during onSystemPrompt middleware or tool execution were not visible to the current/next reasoning round because the call-scoped AgentState was stale relative to the live Toolkit. The fix adds two strategically placed syncToolkitToState() calls (after system prompt consumption and after acting) and introduces tool group activation logic in SkillLoadTool with a sensible fallback chain (param.getAgent().getToolkit() → toolkitRef). The SkillRuntime.install() now refreshes the toolkitRef to prevent stale references. Test coverage is solid, covering all three sync scenarios. The implementation is clean, minimal, and correctly handles null safety throughout. No blocking issues found.

[AgentScopeJavaBot]

[nit] The _skill_tools suffix is duplicated here — the same convention is already encapsulated in RegisteredSkill.getToolsGroupName() (and used inline in SkillBox). Consider extracting it to a shared constant (e.g. AgentSkill.TOOL_GROUP_SUFFIX = "_skill_tools") to avoid silent drift if the naming convention ever changes.

[AgentScopeJavaBot]

[nit] When the toolkit cannot be resolved (both param.getAgent() and toolkitRef fallback return null), the method returns silently. Consider adding a log.debug("activateSkillTools: no toolkit available for skill {}", entry.skill().getSkillId()) here to aid production debugging of skill activation issues.

[AgentScopeJavaBot]

[praise] Good placement — syncing the toolkit's active groups into the call-scoped state right after onSystemPrompt middleware has had a chance to mutate the toolkit ensures the first reasoning round sees dynamically registered tools. The comment clearly explains the rationale.

[AgentScopeJavaBot]

[praise] Correct positioning at the top of the results flatMap, before any branching (stop/suspended/continue). This ensures the state is synced regardless of which exit path is taken, and it happens after all tool executions have completed — so any activateSkillTools calls during acting are properly captured.

[AgentScopeJavaBot]

🤖 AI Review

This PR fixes a real and well-identified issue: dynamic skill tool groups activated during onSystemPrompt middleware or tool execution were not visible to the current/next reasoning round because the call-scoped AgentState was stale relative to the live Toolkit. The fix adds two strategically placed syncToolkitToState() calls (after system prompt consumption and after acting) and introduces tool group activation logic in SkillLoadTool with a sensible fallback chain (param.getAgent().getToolkit() → toolkitRef). The SkillRuntime.install() now refreshes the toolkitRef to prevent stale references. Test coverage is solid, covering all three sync scenarios. The implementation is clean, minimal, and correctly handles null safety throughout. No blocking issues found.

[AgentScopeJavaBot]

[nit] The _skill_tools suffix is duplicated here — the same convention is already encapsulated in RegisteredSkill.getToolsGroupName() (and used inline in SkillBox). Consider extracting it to a shared constant (e.g. AgentSkill.TOOL_GROUP_SUFFIX = "_skill_tools") to avoid silent drift if the naming convention ever changes.

[AgentScopeJavaBot]

[nit] When the toolkit cannot be resolved (both param.getAgent() and toolkitRef fallback return null), the method returns silently. Consider adding a log.debug("activateSkillTools: no toolkit available for skill {}", entry.skill().getSkillId()) here to aid production debugging of skill activation issues.

[AgentScopeJavaBot]

[praise] Good placement — syncing the toolkit's active groups into the call-scoped state right after onSystemPrompt middleware has had a chance to mutate the toolkit ensures the first reasoning round sees dynamically registered tools. The comment clearly explains the rationale.

[AgentScopeJavaBot]

[praise] Correct positioning at the top of the results flatMap, before any branching (stop/suspended/continue). This ensures the state is synced regardless of which exit path is taken, and it happens after all tool executions have completed — so any activateSkillTools calls during acting are properly captured.