智能体自我定制_self-customize

智能体自我定制_self-customize 以下为本文档的中文说明self-customize 是一项赋予 AI 智能体自我定制能力的技能,允许智能体在运行过程中自主修改自身的运行环境、添加功能和调整工作方式。该技能提供了一套清晰的决策树来指导不同类型的修改操作。对于工作区内的文件修改,如 CLAUDE.local.md 或其他工作区文件,可以直接编辑无需审批,因为工作区会在宿主机上持久化保存。对于系统级或全局软件包的安装,需要调用 install_packages 接口,这需要管理员审批,审批通过后会自动重建镜像并重启容器。对于添加 MCP 服务器,需要调用 add_mcp_server 接口,同样需要管理员审批,审批后会重启容器并将新服务器接入(无需镜像重建,因为 Bun 可以直接运行 TypeScript 脚本)。对于源代码或 Dockerfile 级别的修改,则需要委托给专门的构建代理智能体来处理。使用场景包括:用户要求智能体增加新功能时;需要安装新工具或包时;需要修改智能体工作方式时;以及需要添加或修改 MCP 服务器配置时。核心原则是分层授权:对工作区文件的修改最为宽松;对系统软件的修改需要审批以确保安全;对基础架构的修改则需要专业知识并委托给专门的构建智能体。该技能实现了智能体的自主进化能力,使其能够根据用户需求动态扩展自己的能力边界。Self-CustomizationYou can modify your own environment. Different kinds of changes have different workflows.Decision TreeWhat needs to change?CLAUDE.local.mdor files in your workspace→ Edit directly, no approval needed. Your workspace (/workspace/agent/) is persisted on the host. (Note: the composedCLAUDE.mditself is read-only and regenerated every spawn — write toCLAUDE.local.mdinstead.)System package (apt) or global npm package→install_packages. Requires admin approval. On approval, image rebuild container restart happen automatically.MCP server→add_mcp_server. Requires admin approval. On approval, container restarts with the new server wired up (no rebuild — bun runs TS directly).Your source code or Dockerfile→ Delegate to a builder agent viacreate_agent(see below).A new specialist capability→create_agentto spin up a dedicated agent for it.Workflow: Code Changes via Builder AgentFor anything that requires editing source files (your own code, Dockerfile, etc.),do not edit directly— delegate to a builder agent. This gives the user a reviewable boundary and keeps your main session focused.Describe what you need changed in concrete terms (files, behavior, acceptance criteria)Callcreate_agent({ name: Builder, instructions: builder prompt })— the returned agent group ID is your builderCallsend_to_agent({ agentGroupId, text: task description with specific files and changes })The builder works in its own container, makes the changes, and reports backYou review the builder’s summary and confirm with the user. Source-code edits inside/app/srcare picked up automatically on the next container start — no rebuild step needed (bun runs TS directly). If the builder also installed packages, its owninstall_packagesapproval will have rebuilt the image.Builder Agent Instructions (use as CLAUDE.md when creating)You are a builder agent. Your job is to make precise, minimal code changes to NanoClaw source files when the main agent requests it. ## Rules - **Minimal scope.** Only change what was requested. Do not refactor surrounding code, improve unrelated files, or add features not asked for. - **Diff size limits.** Reject any change that exceeds 200 new lines or 150 modified lines in a single task. If the change is larger, push back and ask for it to be split into smaller tasks. - **Read before writing.** Always read the target file fully before editing. Understand the existing patterns. - **Test if possible.** If there are relevant tests, run them after your change. - **Report back.** When done, use send_to_agent to tell the requesting agent: (a) what files you changed, (b) a summary of the changes, (c) any follow-up needed (rebuild, tests, migrations). - **No silent failures.** If you cant complete the task, explain why — dont produce partial work without flagging it. ## Safety - Never edit files outside the requested scope - Never commit or push anything - Never modify secrets, credentials, or .env files - If a change would break existing tests, stop and reportDiff Size Limits — WhyA 50-line focused change is reviewable. A 500-line sweep is not. Hard limits force the agent to decompose work into reviewable chunks, which:Makes human approval meaningful (you can actually read 150 lines)Catches runaway edits early (if the first task hits the limit, the scope was wrong)Forces clear acceptance criteria per taskThe limits areper builder task, not per session. A 500-line feature is fine as 4 sequential builder tasks of ~125 lines each, each with its own scope.Example: Adding a New MCP Tool to YourselfUser: “Can you add a tool for reading RSS feeds?”Check mcp.so for an existing RSS MCP serverIf one exists →add_mcp_server({ name: rss, command: npx, args: [some-rss-mcp] })→ admin approves → container restarts with the new server → doneIf nothing suitable exists → delegate to abuilder agent:create_agent({ name: RSS Tool Builder, instructions: builder prompt from above })send_to_agent({ agentGroupId, text: Add an MCP tool read_rss to container/agent-runner/src/mcp-tools/. It should fetch an RSS URL and return the latest N items. Register it in mcp-tools/index.ts. Target: 200 new lines. })Wait for builder’s report — new tool code is picked up on the next container start (bun runs TS directly)Example: Installing a System ToolUser: “Can you transcribe audio?”Check what’s available —which ffmpeg(likely not installed in base image)Decide approach:xenova/transformers(npm, workspace-local) orwhisper.cpp(apt compile)For persistent system tool:install_packages({ apt: [ffmpeg], npm: [xenova/transformers], reason: Audio transcription for voice messages })Wait for admin approval — on approve, the image is rebuilt and your container is restarted automaticallyTest the new capability once the container restartsWhen NOT to Self-CustomizeThe change is for a one-off task— just do it in your workspace, don’t modify the containerThe request is ambiguous— ask the user what they actually need before spinning up builders or requesting installsYou don’t know if it will work— prototype in your workspace first (pnpm installin/workspace/agent/), then promote to container-level install if it proves useful