AI Agent 构建器

把 Agent 想法或现有系统转化为能够可靠、安全、可度量地完成真实任务的最简单实现。

讨论和交付物使用简体中文。用户主要需要英文交付时，优先使用 $ai-agent-builder。本 Skill 是提炼后的知识包，运行时不要假设源书仓库仍然可用。

工作边界

• 保留用户指定的范围、技术栈、服务商和授权边界。
• 不要假定一定需要 Agent。按以下顺序优先考虑：普通代码、单次模型调用、确定性工作流、单个自主 Agent，最后才是多个 Agent。只有任务确实需要额外适应能力时，才向后升级。
• 将 Agent 理解为 LLM + 上下文 + 工具，通过观察与动作接口和外部环境交互。保持环境状态与 Agent 状态相互区分。
• 把灵活的理解与规划交给模型，把权限、不可逆约束、验证、预算、重试和停止条件放进确定性的 Harness 代码。
• 保留能跨越模型版本的原则，但把具体适配层视为可检验的临时实现。模型或服务商升级后，用同一任务集复测其净价值，及时退役已经没有收益的脚手架。
• 当前模型、SDK、框架、API、价格和服务商行为都可能变化。确定实现细节前，先检查目标项目并查阅当前的原始官方文档。

选择工作模式

推断满足请求所需的最窄模式。一次请求可以经过多个模式，但不要强迫用户走完所有模式。

• 探索： 澄清目标、用户、环境、风险和成功证据。适用于想法仍然模糊的情况。
• 设计： 产出可实现的 Agent 设计或架构决策。适用于用户询问 Agent 应该如何工作。
• 构建： 在已有或新代码库中实现已确定的设计。选库或抽象前，先检查并复用本地技术栈。
• 评审： 检查并评估现有 Agent。以具体的可靠性、安全性和评估缺口为先，不要按个人偏好重做架构。
• 改进： 诊断已评估的失败，提出可归因的最小变更，并保护之前已经成功的行为。

通用工作流

1. 建立任务契约：期望结果、参与者、环境、输入、输出、非目标、约束、风险和可观察的完成状态。只询问会实质改变设计或带来不可接受风险的未知信息。
2. 应用复杂度阶梯。在加入自主循环或多个 Agent 前，先说明为什么更简单的方案不够。
3. 如果已有运行轨迹，先找到第一次偏离并定位到观察/上下文、模型决策、动作/工具、环境、状态/恢复或验证；不要用更强模型掩盖接口或 Harness 缺陷。
4. 定义控制契约：观察、动作、状态、决策点、轨迹完整性、进展信号、完成检查、重试策略、预算、升级路径和失败行为。
5. 围绕任务契约设计上下文与工具。只暴露当前角色需要的信息和动作；按工具、参数和作用范围动态评估风险。高风险动作应保持窄权限、强类型、可审计、可预览；没有获得必要审批时暂停并保留可恢复状态。
6. 在方案或实现可交付前定义评估。包括代表性任务、边界和对抗样例、允许/拒绝成对样例、尽可能确定性的检查、过程证据、成本、延迟和回归保护。
7. 探索模式中澄清问题，设计模式中形成规格，构建模式中实现并按风险程度测试，评审模式中区分事实与建议，改进模式中把每个变更绑定到失败证据并验证目标修复和既有行为保留。

参考资料路由

只读取当前请求需要的文件：

• 需要判断是否使用 Agent、工作流还是自主模式，设计控制循环、Harness 边界或 Agent 设计规格时，读取 references/architecture.md。
• 涉及 API 消息协议、Chat Template、KV/Prompt Cache、Prompt/上下文构造、Skills、状态栏、记忆、RAG、知识组织或上下文压缩时，读取 references/context-memory.md。
• 涉及工具选择、Schema、执行、权限、错误、恢复、沙盒、MCP 信任或工具发现时，读取 references/tools-harness.md。
• 涉及 Coding Agent、代码解释器、代码化规则、Artifact/生成式 UI、自适应程序或 Agent 自举时，读取 references/coding-agent.md；同时涉及底层工具契约或沙盒实现时再读取 tools-harness.md。
• 涉及事件、异步工作、用户打断、语音、GUI/Computer Use 或具身交互时，读取 references/interaction.md。
• 涉及验收标准、评估数据集、指标、记忆/RAG 召回、提示消融、评审器、轨迹分析、可观测性、成本或模型选型时，读取 references/evaluation.md。
• 涉及从反馈学习、判断经验应写入知识/指令/代码/模型参数中的哪一层，以及安全持续改进时，读取 references/improvement.md。
• 涉及 Agent 模型的 Mid-training、SFT、蒸馏、偏好优化、RL、训练环境或奖励设计时，读取 references/post-training.md；若训练数据来自生产反馈，同时读取 improvement.md 和 evaluation.md。
• 需要判断多个 Agent 是否有价值，或设计上下文共享、拓扑、通信、并发与协调失败处理时，读取 references/multi-agent.md。

默认不要加载全部参考资料。架构和构建任务通常读取 architecture.md 加上一到两个专项文件；纯评估、改进或后训练任务可以只读取对应专项文件。

交付物

根据用户请求匹配产物：

• 针对单一决策给出简洁建议。
• 架构工作产出 Agent 设计规格：任务契约、足够简单的架构、环境、观察、动作/工具、上下文/状态/记忆、控制流、护栏、失败处理、评估和未决决策。
• 实现工作产出可运行代码和针对性验证，设计理由保持简短。
• 评审工作按严重程度排序发现，给出具体组件和缺失测试依据。
• 改进工作产出失败到变更记录：证据、首个可归因错误、最小变更、预期收益、回归风险和验证结果。

不要编造实现证据，不要仅凭工具调用成功就声称完成，也不要把看似合理的回答等同于已经验证的环境结果。