在优秀的智能体（Agent）产品中，最成功的往往不是“最灵活”的，而是“最有主见”的。本文探讨了原因与设计原则。简而言之，建议如下：
构建有主见的智能体。
在工具设计与提示词（Prompt）上果断做出决策。目标是让智能体在特定任务上成功，而不是在所有任务上平均发挥。可定制化可以稍后再考虑。
“灵活性陷阱”：智能体需要的是更少的旋钮，而非更多
优秀的产品设计不在于提供无穷选项，而在于让一切自然顺畅地工作。智能体也应如此。
历史上所有令人愉悦的产品体验，本质上都是创作者将自己的理念高度提炼成“无需调试、即刻可用”的界面。对智能体而言，这意味着：
- 减少设置选项（knobs），用户会感谢你。
- 替用户做更多决策与工作。
- 在提示词与工具设计上下苦功——这是把团队知识与观点注入产品的最直接方式。
- 通过内测（dogfooding）与评估（evals）循环改进，用真实使用来验证产品的“主见”是否有效。
“主见—反馈—评估”三者形成了智能体设计的飞轮：团队在实践中形成观点，用户反馈帮助修正观点，评估数据则让迭代有依据。
原则落地：用户不想调温度，他们只想结果
没有用户愿意调整“temperature”或“chunking strategy”。这正是所谓的“灵活性陷阱”——误以为用户想要选择，实际上他们只想要成果。
史蒂夫·乔布斯设计 iPhone 的“一键界面”就是经典案例：表面上限制了交互方式，实则极大提升了体验的确定性。产品依旧功能丰富，但交互路径变得直观可靠。
Cursor 团队的设计哲学很好地诠释了这种思维：
“这个设置真的需要吗？”
“能更少点点击完成吗？”
“能砍掉哪些没人用的功能？”
这正是智能体产品应有的思考方式。
做好“有主见”的工作
具体而言，团队应当：
- 测试所有模型，帮用户筛选出最合适的版本。别迷信通用基准测试（benchmarks），你的用户不会关心“Terminal Bench 2.0”。
- 写出极其详细的提示词（prompts），告诉模型何为“成功”以及如何达成。提示工程从未过时。
- 验证配置选项。每一个需要用户手动决定的选项，其实都是团队“没替用户下决策”的失败。如果确定 Claude Opus 4.5 最适合你的任务，就让它成为默认值。
- 内部反复使用自己的产品（dogfooding）。让团队成为目标用户的真实写照，才能快速发现痛点与机会。
“通用智能体”的神话
一个智能体 = 有主见的外壳（Harness） + 模型（Model）
所谓“外壳”，是指包裹模型的一层设计：包括提示词、工具、上下文管理、文档、子智能体（Subagents）等。所有“主见”都体现在这一层。
当人们说他们想要“通用智能体”时，其实是在做一种权衡：
“我愿意接受较低的任务表现，以换取更少的定制工程投入。”
这在原型验证阶段或许合理，但很多团队选择“通用”，并非出于设计策略，而是尚未明确自己的立场与偏好。
模型与外壳是不可分割的
一个重要观点：模型与外壳是共生的，不能单独评估。
每个模型的“智能”都有明显的尖刺（spiky intelligence）——擅长某些任务、在另一些任务上表现糟糕。
因此，当更换模型时，原本调校好的外壳往往会“崩坏”：提示词行为变化、工具调用失败、新的错误模式出现……
真正关键的问题是：
“这个模型 + 外壳组合，能否稳定完成我的任务？”
而不是：
“这款模型在最新基准测试中是否得分更高？”
这就是为什么团队必须依靠真实任务、真实用户和自我试用来验证效果。
起点应“深而窄”
如果“通用”是妥协，那么最佳策略是从深而窄的任务入手：
- 聚焦一个具体任务。
- 减少交互面。
- 让少数关键行为做到极致稳定。
常见两种错误倾向：
- 面太广（wide agent）：试图处理太多任务，导致漏洞与混乱激增，演示漂亮、生产灾难。
- 太浅（shallow agent）：逻辑过于简单，不值得独立成为智能体。若无判断与多步推理，可能只是一个工作流，而非 Agent。
最优点是“窄到可以精细打磨，深到足以产生价值”。先找到那 10% 的高价值任务，集中精力攻克它。
连模型实验室也在变得“有主见”
如今，各大模型公司（如 Anthropic）也在为特定领域打造专门团队。
并非要训练新的金融或生命科学专用模型，而是要为这些任务优化外壳与工具体系。
这种“任务导向的主见性设计”比堆参数更能带来稳定表现。Claude Code、Codex 等产品正是如此：在外壳层面内置上下文管理、文件系统、子智能体，让用户无需从零配置。
类似地，LangGraph、LangChain 提供了通用抽象，而后来的 DeepAgents 则在其上进一步加入了“有主见的预设”：文件系统支持、内置规划工具、默认提示等。
好的默认值（opinionated defaults） 本身就是竞争力。
Amp Code 也是如此。它专注单一任务——代码开发。团队通过高强度的自测，将经验直接写入产品中，包括默认模型、辅助智能体（如 Librarian）等。用户无需选择繁多选项，只需专注于成功写出代码。
如何让智能体“更有主见”
今天，大多数智能体产品的问题在于：选项太多，观点太少。
要改变这一点，可以从以下几步做起：
- 审视所有配置项。 对每一个用户选项，问自己：“我们是否已经知道正确答案？” 如果知道，就固定下来；如果不知道，那是团队需要研究的问题。
- 聚焦单一任务。 “帮助用户做 X” 太模糊。应当定义为“完成具体流程 Y”，并对该流程优化到极致。
- 用任务评估模型，而非基准测试。 问题不是“Opus 4.5 比 Gemini 3 Pro 强吗？” 而是“哪个模型与哪种外壳组合在我的任务上更可靠？”
“通用”工具的讽刺在于——它让用户承担了复杂性。
而“有主见”的设计更困难，因为这要求开发者做艰难抉择、承担风险、面对外界批评。
但也正因如此，它往往产出更好的产品。
结语
真正优秀的智能体并不追求“面面俱到”，而是敢于在设计中“有立场、有取舍”。
它们通过主见、反馈与验证不断进化，最终让用户几乎感觉不到背后的复杂性，只感受到：它真的好用。
愿未来的智能体产品，都能更有主见。