最近在 Agent 设计中遇到了一个本来很简单的问题：用户输入后，如何判断应该追问还是直接执行？
最初的方案中，我很自然的写了这样一条规则：
如果用户输入是明确需求，则直接执行
如果用户输入是模糊需求，则先追问
本以为这就足以解决问题（靠模型的聪明才智），但是事实上，这引出了一系列更大的问题：什么算"明确"？什么算"模糊"？边界在哪里？
为了让判断更准，覆盖新发现的边界情况，我们不断叠加更多规则。为了处理特殊场景，又加了异常分支。
结果？规则越来越多，效果越来越差，上下文指数级膨胀，之后就是不断的优化规则，不断的优化示例。
最近停下来思考，我突然意识到，一切都始于最初那两条规则。也许从一开始，通过制定规则来解决问题的思路就错了。
一、规则判断+分支的思维习惯已过时
传统软件开发的习惯思路：
判断 → 分支 → 执行
用 if-else 预判所有情况，用规则控制每个分支，追求确定性输出。这在传统软件里完全正确。但问题是。
从输入来说：规则、系统提示等等这些预置的东西，大模型不会按顺序看到。
从输出来说：模型并不会真正分步骤执行，而只是预测下一个token，来假装按规则执行。
所以，当我写：
如果用户输入是明确需求，则直接生成
如果用户输入是模糊需求，则先追问
模型看到的不是"两条可执行的 if-else"。它看到的是"一段描述某种行为模式的文本"。
所以实际上模型只是在尝试扮演一个规则执行者，这也许就是“降智”“概率”等问题发生的原因。
这种思维方式设计的agent，会让大模型丧失他真正擅长的理解意图，把握上下文，自然地响应。
像一个很会聊天的人，告诉他说话前要从这个词典中找到对应的词，然后原封不动的说。
看看行业大佬的案例，Anthropic 在与数十个团队合作构建 Agent 后，给出了一个明确的结论：
"最成功的实现并没有使用复杂的框架或专门的库。相反，它们使用的是简单、可组合的模式。"— [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)
二、规则和示例，低效占用上下文资源
意识到这点后，我想：那 few-shot 示例来代替规则呢？问题是，当你需要越来越多的例子去覆盖边界情况时，你其实还是在"枚举"。
规则 = 显式枚举边界
示例 = 隐式枚举边界
两者本质相同：你在说"我不信任你的理解能力，让我来告诉你边界在哪里"。
而且都会导致同一个问题：上下文膨胀。
Anthropic 在研究中发现了一个叫 "Context Rot"（上下文腐烂） 的现象：
随着上下文窗口中 token 数量增加，模型准确回忆信息的能力会下降。
这不是简单的"信息太多记不住"。技术原因在于 Transformer 架构本身：每个 token 都要和其他所有 token 建立注意力关系，n 个 token 就是 n² 个关系。10,000 个 token = 1 亿个关系需要维护。
很多研究都表明：在真实任务（而非简单的 Needle-in-Haystack 测试）中，随着上下文长度增加，模型性能下降更为严重——尤其当问题和答案的相似度较低时。
所以规则越多、示例越多，模型反而越容易迷失在这堆文本里。
三、从提示词工程到上下文工程
我们先跑个题，当做扩展阅读。提示词和上下文工程是个老词，但我还是想重新拿出来理解一下
Anthropic 给出了明确的区分和建议：
Prompt Engineering = 优化单次指令的写法
Context Engineering = 设计和维护模型在推理时看到的整个 token 集合
找到最小的高信号 token 集合，最大化期望输出的可能性。
换句话说：不是往上下文里塞更多规则，而是精心策划哪些信息应该出现在模型的注意力范围内。
四、最佳实践 – 顶级Agent产品都很"简单"
让题再跑一会，我们来看几个coding工具的案例
Claude Code 的设计哲学是：
"低层级、不预设立场，提供接近原始模型访问。"
Cursor：
系统提示完全静态（为了利用 prompt caching 降低成本）。
Rules 不是塞进 prompt 里，而是作为"可查询的资源"——模型需要时才调用 `fetch_rules(…)` 加载。
模型决定什么时候需要规则，而不是规则一直压在模型头上。
OpenAI Codex：
单 Agent ReAct 循环。用 AGENTS.md 提供项目上下文，不是规则清单。
沙盒执行，允许错误发生，通过人类验证来纠正。
这些产品的共同点不是"规则设计得更好"，而是他们主要让模型了解目标（他能做什么、他要做什么）。
它们用的是另一种更适合大模型的工具设计方式（也许可以叫声明式）：
上下文 → 推理 → 响应
不是告诉模型"什么时候做什么"，而是设计好上下文环境，让模型自己推理出正确的行为。
Anthropic 的工具优化实验
Anthropic 分享了一个案例：他们发现 Claude 在使用 Web Search 工具时，会自动给搜索词加上"2025"，导致搜索结果偏差。
解决方法不是写一条规则说"不要加年份"，而是优化工具描述，明确说明搜索词应该怎么写。
"即使是对工具描述的微小改进，也能带来显著的性能提升。"
他们还做了一个实验：用一个 Agent 来测试和优化工具描述。这个 Agent 会反复使用工具，记录失败情况，然后重写工具描述来避免这些失败。
结果：优化后的工具描述让后续 Agent 的任务完成时间减少了 40%。
这说明工具描述是最被低估的设计杠杆。
它不是 API 文档，而是行为引导——模型通过理解工具的能力和约束，自己推理出正确的使用方式。
五、让工具约束引导模型行为
我们来看看开篇提到的问题按照以上思路应该如何解决
我之前的做法：
写规则：如果包含具体颜色、尺寸、内容，判定为明确需求，直接执行；否则判定为模糊需求，先追问…
工具约束引导：
name: generate_image
description:
根据详细的画面描述生成图片。
需要完整的画面描述，包括主体、背景、颜色、构图。
如果输入过于简单，将无法产生满意结果。
name: expand_prompt
description: |
将简单的想法扩展为详细的画面描述。
当用户说"帮我做个海报"时，模型看到这两个工具描述，会自己推理：
"用户输入是'帮我做个海报' → 我要调用生图工具 → 但它需要详细描述 → 我手上的输入不够详细 → 我需要先调用扩写工具"
我没有写任何"如果模糊则…"的规则。 模型通过理解工具的输入约束，自己推导出了正确的行为。
这种方法有人专门写过一篇文章讨论，叫 Tool-Driven Behavioral Directives：
"每个工具携带自己的行为上下文。当工具运行时，它不仅返回数据，还返回告诉 Agent 如何处理数据的指令。"— [Tool-Driven Behavioral Directives](https://dev.to/ricardo_brandao_07d4efc5/how-to-control-agents-without-massive-system-prompts-hnn)
作者在生产环境测试的结果：98% 的规则遵循率，且无需扩展系统 prompt。
六、写在最后
模型在预训练中已经学会了大量"意图→行为"的模式。遇到问题时，不要想“告诉模型该怎么做”，要扫清阻碍模型做出正确行为的障碍。我们加的那些规则，很可能是在覆盖它已有的能力，而不是增强它。
Anthropic 在 Agent 设计指南中说：
"LLM 可能会运行多个回合，你必须对它的决策能力有一定程度的信任。"
这不是说完全不加控制。而是说：
设计"可纠正的交互"，而不是"永远正确的规则"。
Claude Code、Cursor、Codex 都采用这种模式：
– 沙盒执行
– 结果验证（linting、编译检查、测试）
– 人类审核
– 迭代改进
与其试图让 AI 永远不犯错，不如设计一个"犯错后能快速纠正"的系统。
总结一下：
1. 删掉分类规则
之前写的那些"如果 X 类型则执行 A"，尝试用工具约束替代。
2. 优化工具描述
Anthropic 的建议：
– 选择高杠杆工具：专注于能显著扩展 Agent 能力的工具，而不是现有 API 的薄封装
– 清晰命名和区分：避免功能重叠导致模型困惑
– 返回有意义的上下文：人类可读的字段，而不是原始 ID
– 控制输出长度：实现分页、截断、过滤，避免撑爆上下文
"工具描述是 prompt。名称、描述、参数文档中的每个词都在塑造 Agent 理解和使用工具的方式。"
3. 给目标，不给方法
4. 按需加载上下文
—
如果文章对你有所帮助。推荐下我开源的一个项目 1000+ X 热门 Nanobanana Prompts 每周更新
延伸阅读
-
[Building Effective Agents (Anthropic)](https://www.anthropic.com/research/building-effective-agents) — Agent 设计的核心原则
-
[Effective Context Engineering for AI Agents (Anthropic)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — 上下文工程方法论
-
[Writing Tools for Agents (Anthropic)](https://www.anthropic.com/engineering/writing-tools-for-agents) — 工具设计最佳实践
-
[Claude CodeBest Practices](https://www.anthropic.com/engineering/claude-code-best-practices) — Claude Code 的设计哲学
-
[Claude Code Built-in Tools Reference](https://www.vtrivedy.com/posts/claudecode-tools-reference) — 工具描述详解
-
[Cursor Architecture Deep Dive](https://medium.com/@lakkannawalikar/cursor-ai-architecture-system-prompts-and-tools-deep-dive-77f44cb1c6b0) — Cursor 架构分析
-
[Tool-Driven Behavioral Directives](https://dev.to/ricardo_brandao_07d4efc5/how-to-control-agents-without-massive-system-prompts-hnn) — 工具驱动的行为控制
-
[Context Rot Research (Chroma)](https://research.trychroma.com/context-rot) — 上下文腐烂的技术研究
