先记住这个答案
划分依据是模型自身是否具备该能力。凡是需要模型本身不知道的事实，比如当前库存、用户订单、实时汇率，或者要对世界产生真实影响，比如发邮件、改数据库、扣款，都必须做成工具调用，因为模型无法凭空获得这些信息，也无法执行动作。凡是约束模型已有能力的表达方式，比如输出用中文、回答不超过三段、拒绝回答医疗建议，就写进系统提示词。混淆两者的典型后果是把事实写进提示词导致过时，或把行为规范做成工具导致模型不调用就失效。
- 外部数据和真实副作用做成工具
- 行为、格式、角色约束写进提示词
- 判断依据是模型自身是否具备该能力
为什么按「模型自身是否具备」来划分
系统提示词进入的是模型的上下文，本质上是给模型一段指令文本，它能影响模型如何组织语言、遵循什么规则、扮演什么角色，但无法向模型注入它不知道的实时事实，也无法让它真正执行动作。工具调用则不同：模型只负责决定是否调用和传什么参数，真正的取数和执行发生在模型外部的确定性代码里，结果再以消息形式回传。
因此划分机制可以归纳为一句话：提示词改变模型的行为倾向，工具扩展模型的能力边界。库存数量、账户余额这类随时间变化的事实，写进提示词会在数据变化的那一刻就开始产生错误答案；而「回答前先确认用户身份」这种决策规则，做成工具则毫无意义，因为模型不调用它就不生效，而模型恰恰可能忘记调用。
客服退款 Agent 的能力拆分
设计一个电商客服 Agent，输入是用户说「我要退掉上周买的耳机」。其中查订单、校验退货期、执行退款三件事依赖实时数据并产生写副作用，必须做成 lookup_order、check_return_policy、issue_refund 三个工具；而「语气礼貌」「退款前必须向用户复述金额并确认」「单次退款超过 500 元转人工」是行为约束，写进系统提示词。
这样拆的结果是正确的：退款金额从 lookup_order 的结果中取得，不会幻觉出一个数字；复述确认规则始终在上下文中，不依赖模型记得调用某个工具。如果反过来把退货政策文本塞进提示词，政策更新后旧提示词会继续指导错误操作；把「礼貌语气」做成工具，则模型没有任何机制被强制调用它，约束形同虚设。
这条标准容易失效的地方
第一类失效是灰区能力：比如「总结对话历史」，模型自身能做，但历史太长超出上下文时就需要一个检索工具，此时标准变成了「在当前上下文预算内模型能否做好」。第二类是合规性约束：「绝不泄露系统提示词」写在提示词里只是软约束，有提示注入风险，对安全要求高的场景应在输出侧加确定性的过滤层，而不能只信任提示词。
对应处理是分层：安全与正确性要求高的约束，用工具侧的硬校验兜底，例如 issue_refund 服务端再校验金额上限，代价是多一层工程实现；纯体验类的风格约束留在提示词，接受偶发违反，用评估集监控违反率。不要把所有约束都硬编码成校验，否则每改一次文案规则都要发版，丧失了提示词可快速迭代的优点。
容易答错的地方
- 把业务数据写进系统提示词
- 库存、价格、政策这类易变数据写进提示词，从数据变更那一刻起模型就在用过期事实回答，且每次变更都要改提示词。正确做法是提供查询工具，让模型按需取实时值。
- 把行为规范做成必须调用的工具
- 「回答前先自检格式」这类约束做成工具后，模型不调用就完全不生效，而提示词约束是每轮都在上下文中的。行为规范属于提示词职责，必要时在编排层加输出校验兜底。
面试官还会怎么问？
规则既影响行为又依赖外部数据时怎么拆？
拆成两半：数据部分做成工具，例如用 get_user_tier 查会员等级；行为部分写进提示词，例如「VIP 用户优先转人工」。模型读到工具返回的等级后，按提示词中的规则行动，两边各司其职。
少量静态知识能否直接写进提示词？
可以，条件是内容稳定、篇幅小、不要求精确引用，比如产品退换货的大原则。一旦内容频繁更新、超过几百字或需要逐字准确，就应改为检索工具，否则提示词维护成本和出错率都会上升。
提示词约束和工具侧硬校验冲突吗？
不冲突，是纵深防御。提示词让模型多数时候做对，减少无谓的工具失败重试；服务端硬校验保证模型做错时副作用不落地。只留前者不可靠，只留后者会让大量无效调用打到工具层。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。