name: agent-builder description: | 为任何领域设计和构建 AI 代理。在用户以下情况时使用： (1) 要求"创建代理"、"构建助手"或"设计 AI 系统" (2) 想要了解代理架构、代理模式或自主 AI (3) 需要关于能力、子代理、规划或技能机制的帮助 (4) 询问 Claude Code、Cursor 或类似代理的内部工作原理 (5) 想要为业务、研究、创意或运营任务构建代理 关键词：agent, assistant, autonomous, workflow, tool use, multi-step, orchestration
代理构建器
为任何领域构建 AI 代理 - 客户服务、研究、运营、创意工作或专门的业务流程。
核心理念
模型已经知道如何成为代理。你的工作是让开道路。
代理不是复杂的工程。它是一个简单的循环，邀请模型行动：
循环：
模型看到：上下文 + 可用能力
模型决定：行动或回应
如果行动：执行能力，添加结果，继续
如果回应：返回给用户
就是这样。 魔力不在代码中 - 它在模型中。你的代码只是提供机会。
三大要素
1. 能力（它能做什么？）
代理可以执行的原子操作：搜索、读取、创建、发送、查询、修改。
设计原则：从 3-5 个能力开始。仅当代理因为缺少能力而持续失败时才添加更多。
2. 知识（它知道什么？）
按需注入的领域专业知识：政策、工作流程、最佳实践、模式。
设计原则：让知识可用，而不是强制。在相关时加载，而不是预先加载。
3. 上下文（发生了什么？）
对话历史 - 将行动连接成连贯行为的线程。
设计原则：上下文是宝贵的。隔离嘈杂的子任务。截断冗长的输出。保护清晰度。
代理设计思维
在构建之前，了解：
- 目的：这个代理应该完成什么？
- 领域：它在什么世界中运作？（客户服务、研究、运营、创意...）
- 能力：哪 3-5 个行动是必不可少的？
- 知识：它需要访问哪些专业知识？
- 信任：你可以将哪些决定委托给模型？
关键：信任模型。不要过度工程。不要预先指定工作流程。给它能力并让它推理。
渐进式复杂性
从简单开始。仅当实际使用显示需要时才添加复杂性：
| 级别 | 添加什么 | 何时添加 |
|---|---|---|
| 基础 | 3-5 个能力 | 总是从这里开始 |
| 规划 | 进度跟踪 | 多步骤任务失去连贯性时 |
| 子代理 | 隔离的子代理 | 探索污染上下文时 |
| 技能 | 按需知识 | 需要领域专业知识时 |
大多数代理永远不需要超越第 2 级。
领域示例
业务：CRM 查询、电子邮件、日历、审批 研究：数据库搜索、文档分析、引用 运营：监控、工单、通知、升级 创意：资产生成、编辑、协作、审查
模式是通用的。只有能力会改变。
关键原则
- 模型就是代理 - 代码只是运行循环
- 能力赋能 - 它能做什么
- 知识告知 - 它知道如何做什么
- 约束聚焦 - 限制创造清晰度
- 信任解放 - 让模型推理
- 迭代揭示 - 从最小开始，从使用中演进
反模式
| 模式 | 问题 | 解决方案 |
|---|---|---|
| 过度工程 | 需要前的复杂性 | 从简单开始 |
| 太多能力 | 模型混淆 | 开始时 3-5 个 |
| 僵化工作流程 | 无法适应 | 让模型决定 |
| 前置加载的知识 | 上下文膨胀 | 按需加载 |
| 微观管理 | 削弱智能 | 信任模型 |
资源
哲学与理论：
references/agent-philosophy.md- 深入探讨代理为什么有效
实现：
references/minimal-agent.py- 完整的工作代理（约 80 行）references/tool-templates.py- 能力定义references/subagent-pattern.py- 上下文隔离
脚手架：
scripts/init_agent.py- 生成新代理项目
代理思维方式
从："我如何让系统做 X？" 到："我如何让模型能够做 X？"
从："这个任务的工作流程是什么？" 到："哪些能力有助于完成这个任务？"
最好的代理代码几乎是无聊的。简单的循环。清晰的能力。干净的上下文。魔力不在代码中。
给模型能力和知识。信任它来弄清楚其余的。