你的 AI Agent 总「越界」？这个 Skill 把边界写死

为什么你的 AI Agent 总「越界」？

你有没有这种经历：你明明做了一个「客户关系管理 Agent」，结果它某天突然开始帮你写 Python 脚本、回答百科知识，甚至给你起外号。不是因为它坏，而是因为大多数 Agent 的三层边界根本就没对齐：prompt 说一套、工具做一套、执行时又漏了一套。

这其实是当前 AI 开发里非常常见的一个「隐性 bug」。我们花很多时间调模型、堆上下文，却很少把「这个 Agent 到底能做什么、不能做什么」写死。结果就是 Agent 的表现全靠模型「自觉」，而模型的自觉往往并不可靠。

write-agent：用工程化思路修 Agent 的「scope creep」

GitHub 上有一个叫 write-agent 的 Skill，专门解决这个问题。它不是教你写更好的 prompt，而是教你用系统设计的方式重新框定 Agent 的边界——从 prompt、工具、guardrails 三个层面同时对齐，让 Agent 真正「只做它该做的事」。

它的核心逻辑非常直白：

• 先写一句 job description：这个 Agent 的唯一职责是什么？如果你需要用「而且还要…」来解释，那说明你需要拆成两个 Agent。
• 再列能力清单和非目标：哪些事它必须做，哪些事它绝对不能碰。这里特别强调「YOU ARE NOT a general assistant」这种否定式约束。
• 让工具集成为能力边界：最强的「我不能做」不是写在 prompt 里，而是直接不给对应工具。没有工具，就没有能力，也就没有幻觉。

这套方法论对现在大量「Agent 乱飞」的场景特别有效。很多团队在做企业级 AI 助手时，Agent 经常在客户数据、内部知识、外部搜索之间乱跳，原因不是模型差，而是边界没在设计层面锁死。

适合谁用？

如果你正在做以下任何一种事情，这个 Skill 值得一读：

• 从零搭建一个功能明确的 LLM Agent
• 现有 Agent 经常跑题、越权、回答不在服务范围内的问题
• 需要给 Agent 加「域内能力」和「域外拒绝」的双层控制
• 对「prompt 只是装饰，工具才是真边界」这件事有体感

它不是那种「换个模型就能好」的安慰剂，而是实打实地把 Agent 设计成「少即是多」的工程实践。推荐给所有对 Agent 稳定性有要求的同学。

项目地址：https://github.com/hawkyre/hawk-skills/tree/main/skills/write-agent

GitHub: https://github.com/hawkyre/hawk-skills/tree/main/skills/write-agent