Commit Graph

9 Commits

Author SHA1 Message Date
matevip
728ed53062 feat(skill): scope agent runtime skill resolution to the conversation workspace 2026-07-24 14:12:08 +08:00
倪程伟
3d8d266e3b
fix(skill): enforce agent skill bindings in skill meta-tools at runtime (#265)
The skill meta-tools (listAvailableSkills, readSkillFile, listSkillFiles, load_skill, runSkillScript) queried the full skill catalog without checking the calling agent's bindings, so an agent scoped to a subset of skills could still read, load, or execute any skill via direct tool calls. Resolve the agent's bound skill ids from the tool context and filter/deny accordingly: a null binding set means no restriction (backward compatible), a non-null set (including empty) restricts access to that set — matching the system-prompt catalog filtering.

Closes #264
2026-06-07 17:30:41 +08:00
matevip
123d912f84 fix(skill): allow template file access 2026-05-23 09:08:01 +08:00
matevip
5789a28e19 feat(skill): boost newly installed skills + teach LLM to widen the catalog search 2026-05-12 17:20:09 +08:00
matevip
42d406ffc8 fix(agent): drop brittle output policing, add evidence-grounded long-task safeguards 2026-05-04 11:55:44 +08:00
matevip
3d50b9c132 feat(skill): catalog sort + usage stats 2026-05-04 11:55:35 +08:00
matevip
101aa3209e fix(skill): stop the LLM from calling skill names as tools (issue #46)
When a user-installed skill (e.g. RedisOps) was bound to an agent, the
model frequently called the skill name directly as a tool, hit
"Tool not found: RedisOps", and either gave up or fell back to shell
guessing. Two compounding causes:

1. The system prompt block injected by SkillRuntimeService listed each
   skill as `- **RedisOps** — desc`, which is the same format used for
   tool catalogs and primed the model to call the names directly. The
   "how to use" instructions referenced `read_skill_file` /
   `run_skill_script` — names that don't exist in the tool registry,
   so even a compliant LLM couldn't follow them.

2. ToolExecutionExecutor's `callback == null` branches returned a bare
   "Tool not found: <name>" string. The model had no recovery signal
   and no hint that the name it called was actually a skill.

Fix is two-layered:

- Prompt rewrite (SkillRuntimeService.buildSkillPromptEnhancement): lead
  with an explicit warning that skills are NOT directly callable, use the
  correct camelCase tool names (readSkillFile / runSkillScript), include
  a concrete worked example anchored to the first enabled skill, and
  render the listing as a markdown table so it stops looking like a
  callable tool list. listAvailableSkills tool description and output
  follow the same pattern.

- Runtime safety net (ToolExecutionExecutor): when toolCallbackMap.get
  misses, check if the requested name (case-insensitive) matches an
  active skill. If so, return a precise hint telling the LLM the right
  invocation pattern instead of the bare error. Wired through both the
  main execute path and the pre-approved replay path. SkillRuntimeService
  is attached via a setter from AgentGraphBuilder so the executor's many
  legacy constructors stay untouched, and it's nullable so isolated
  tests still work.

Adds 5 unit tests covering: skill match -> hint, case-insensitive match,
no-match -> bare error, no SkillRuntimeService wired -> bare error,
pre-approved replay path -> hint.

Reported and reproduced by @pipima9950-glitch in issue #46.
2026-04-30 16:36:30 +08:00
matevip
367dd4bed0 fix(agent): preserve per-subtask results in multi-task answer synthesis, add listAvailableSkills tool 2026-04-10 17:10:02 +08:00
matevip
579d60125b Initial commit: MateClaw — Java + Vue 3 AI Assistant System
Full-stack AI assistant built on Spring AI Alibaba.
Features: ReAct Agent, Plan-and-Execute, MCP Protocol, Multi-Model, Multi-Channel.

Apache-2.0 License
2026-04-04 19:03:49 +08:00