GitHub user alnzng added a comment to the discussion: Agent Skills Integration Design
@wenjin272 Great proposal! The progressive disclosure model, SKILL.md format, and three-level scoping are solid design. The instruction-only approach with 3 built-in tools (`load_skill`, `execute_shell_command`, `load_skill_resource`) matches how [Anthropic's official skills](https://github.com/anthropics/skills) work. After going through the design, I have some thoughts below. Would love to discuss with you and the community. ### 1. Skill-Tool Binding: Reducing Global Tool Count Flink Agents supports function calls as tool calls. Each skill can trigger function calls and also execute its bundled scripts. The scripts part is well designed, each skill has its own `scripts/` folder, isolated from other skills. But there is a gap on function calls side. Current design only supports static tool list defined globally on ChatModel (`BaseChatModelSetup.tools`). Agent will enable all tools in every LLM call. When multiple skills are imported, and each skill needs its own function calls, the global tool list can become large. Research shows this is real problem: reducing tool count improves LLM function-calling accuracy, cost efficiency, and reasoning quality: - https://blog.langchain.com/react-agent-benchmarking/ - https://www.getmaxim.ai/blog/tool-chaos-no-more-how-were-measuring-model-tool-accuracy-in-the-age-of-mcp/ - https://arxiv.org/abs/2411.15399 - https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools **Suggestion:** Add mechanism to define tool list per skill. Model-level tool list only defines global minimum tool set (e.g. the 3 built-in skill tools). When LLM loads a skill, that skill's tools become available. When no skill is active, LLM sees only base tools plus skill catalog in system prompt, enough to discover and load the right skill. Looking at existing Flink Agents API, each resource type has its own decorator (`@chat_model_setup`, `@tool`, `@prompt`, `@mcp_server`), each with per-instance configuration. Following same pattern, a `@skill` (singular) decorator can provide per-skill tool binding: ```python class MyAgent(Agent): @skill @staticmethod def data_analysis() -> ResourceDescriptor: return ResourceDescriptor( clazz=ResourceName.SKILL, path="/opt/skills/data-analysis", tools=["query_api", "generate_report"], # Tools bound to this skill ) @skill @staticmethod def monitoring() -> ResourceDescriptor: return ResourceDescriptor( clazz=ResourceName.SKILL, path="/opt/skills/monitoring", tools=["check_status"], # Different tools for this skill ) ``` ### 2. Repository Abstraction: Pluggable Skill Sources The proposed `AgentSkillManager` handles all source types directly, loading from filesystem paths, JAR resources, and URLs in separate private methods (`_load_skills_from_paths()`, `_load_skills_from_resources()`, `_load_skills_from_urls()`). Adding new skill source like Git repos, databases, or MCP servers requires modifying manager class itself. As skill ecosystem grows and community wants to fetch skills from more sources, this becomes bottleneck. **Suggestion:** Extract pluggable `AgentSkillRepository` interface with built-in implementations for current three sources (filesystem, classpath, URL). `AgentSkillManager` delegates to repositories instead of handling each source type directly. When `@skill` decorator specifies a `path`, it uses `FileSystemSkillRepository`; a `url` uses `URLSkillRepository`, and so on. This also enables MCP-based skill sources mentioned in Future Works: McpSkillRepository` can plug in without touching `AgentSkillManager`. GitHub link: https://github.com/apache/flink-agents/discussions/565#discussioncomment-16304889 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
