## 创建一个 Agent 完成一个可持续使用的 Agent 创建闭环： - 名字清楚 - 长期职责清楚 - 边界清楚 - Runtime 可用 - 创建后能在真实协作空间里被稳定唤起 本章只讲单个 Agent 的建立与首次验证，不讨论多 Agent Team 编排。 ```text 我要创建一个 Agent。 请按产品说明书口径检查这几件事是否已经明确： 1. 名称 2. 长期职责 3. 边界与停止条件 4. 应绑定的 Runtime 5. 创建后如何验证它真的能工作 ``` 创建第一个 Agent，不是填完一个表单就结束，而是要完成一次真实协作闭环。 ### 第一步：先定义它为什么存在 在创建前，先回答一个问题：团队以后会在什么情况下稳定地 `@` 这个 Agent。 如果这个问题回答不出来，就不应该急着创建。因为 Agent 是长期协作成员，不是一次性任务容器。一个缺少明确职责的 Agent，后续很快就会变成： - 大家不知道什么时候该叫它 - 叫到它时，输出范围忽大忽小 - 与其他 Agent 或人类成员发生职责重叠 因此，创建前要先确定它负责哪类长期结果，例如： - 代码评审 - 发布协调 - 需求拆解 - 文档整理 - 故障排查 ### 第二步：给它一个可复用的名字 名字应该像岗位，而不是像情绪化代号。 例如 `frontend-reviewer`、`release-helper`、`doc-organizer` 这类名称，团队一看就能知道这个 Agent 大概负责什么。相反，如果命名成抽象绰号或只对创建者本人有意义的简称，团队在实际协作里很快就会失去判断依据。 名称不是装饰，它直接影响团队是否能稳定记住并唤起这个成员。 ### 第三步：写最小但准确的职责说明 创建时，不需要把 Role 写得过长，但必须把最关键的三件事交代清楚： 1. 它长期负责什么结果 2. 它默认如何与团队协作 3. 它不直接处理什么问题 这一步的关键不是“写得多”，而是“定义准确”。 ### 第四步：绑定一个真正可用的 Runtime Role 只定义职责，不保证能力。 真正决定这个 Agent 能不能工作的是 Runtime。创建时至少要确认： - 当前机器是否在线 - Runtime 是否已经启动 - 所需模型是否可用 - 必要工具是否已开放 - 它是否能访问当前任务最需要的资源 如果一个 Agent 负责代码评审，但 Runtime 不能读仓库；或者它负责排障，但 Runtime 不能执行只读诊断命令，那么这个 Agent 虽然“创建成功”，实际上并没有形成可用成员。 ### 第五步：创建后立刻做真实唤起测试 Agent 创建完成以后，真正需要验证的不是“按钮点完了没有”，而是协作闭环是否成立。 更合理的做法是：创建后立刻到低风险 channel 或 thread 中做一次真实唤起测试，再用 2 到 3 条真实消息检查它是否能稳定进入职责状态。 首次测试优先看 4 件事： - 能不能被准确 `@` 到 - 会不会稳定回应 - 回应是否落在职责范围内 - 在信息不足时会不会停下来提问，而不是直接越界 ### 第六步：不要一开始就把所有东西都配满 创建时，优先配置最必要的三类信息： - 名称 - 短职责说明 - 最必要的 Skills 或资源绑定 不要一开始就把所有能想到的 Skill、工具、外部接入全部挂上去。那样做的结果通常不是更强，而是更混乱：你很难判断问题到底出在 Role、Skill 还是 Runtime。 ### 一个最小闭环示例 一个最小可用的评审 Agent，可以先只具备这些内容： - 名称：`reviewer-bot` - 职责：负责检查实现边界、依赖影响和验证证据 - Skill：基础 review 清单 - Runtime：能读仓库、看 diff、执行少量只读命令 创建完成后，到一个低风险 thread 里发两三条真实消息，看它是否能： - 进入评审角色 - 输出结构化结论 - 在证据不足时要求更多上下文 如果这三件事做不到，就不应该继续往它身上叠加更多能力，而是先把当前闭环修好。 创建时，优先明确：名称、职责说明、边界、Runtime、最必要的 Skill。 创建成功但叫不起来时，先检查： - 机器是否在线 - Runtime 是否可用 - 名称是否写对 - 当前空间里是否真的能 `@` 到它 - 资源权限是否满足最小协作需要 涉及公共 channel 使用、高权限工具或共享资源访问时，最好先确认团队是否同意这个 Agent 以该角色公开协作。 先把消息闭环跑通，再逐步接入代码托管、搜索、文档、浏览器或其他外部系统能力。 读完本章后，读者应该能完成一次真正可用的 Agent 创建：不仅在界面上创建成功，而且能在真实协作中被唤起、进入职责状态并稳定回应。