别再堆 MCP 工具了！好用的 AI Agent，始于一个“懂你”的 System Prompt

前言：有了 MCP，就有好用的 AI Agent 了吗

MCP 还在持续火热，开源和企业内部平台正在提供 API 一键转成 MCP Server 的能力，越来越多的 MCP 工具催生了 Awesome MCP Servers 这样的“开源工具商店”，像极了互联网初期的 hao123 网址导航。

MCP AI 能调用的工具已经琳琅满目，但开发者对于如何把 AI 集成到自己的系统内还是一头雾水。在深入学习 Cline 的 System Prompt 后，我发现 MCP 工具协议固然重要，但做好 Agent 更重要的是 System Prompt，那是 Agent 的“灵魂”或“人格”。当然，System Prompt + MCP 也不是 Agent 的全部，好用的 Agent 就像找对象一样，需要用户在对的时间、对的地点遇到对的 Agent，才会有丝般顺滑的使用感受。

MCP 是大模型的“USB Type-C”，但用户需要的是一个好用的 AI APP。如何做出一款好用的 AI APP，是本文想要讨论的话题。

一、存在形式：是 AI Agent 还是 Agentic AI？

很多人都在说 2025 是 AI Agent 元年，Agent 可以自主完成需求分析、执行工具、交付最终结果。前段时间爆火的 Manus 让更多人对 Agent 有了更感性的认识：做旅行攻略、订机票、简历筛选、股票分析等，甚至 Manus 的界面和 Todolist 的设计都被认为是 AI Agent 的标配。一时间，各种 Manus 同款纷纷上线，只留下我对着“今天你想做点什么”的对话框不知所措。Agent 真的只能是这样吗？

前几天，吴恩达和 LangChain 的联合创始人展开了一场对话，他又阐述了一遍自己 Agentic 的理念：与其争论某个实现是不是 Agent，有没有自主性，不如把“Agenticness（代理性）”看作一个连续的光谱，有些系统的 Agentic 强一些，有些弱一些。我深以为然。

Agent 和 Agentic 的争论让我想起前几年的“互联网+”和“+互联网”路线之争。曾经很多互联网企业想用“互联网”手段把所有传统行业重做一遍，但几轮补贴烧钱之后一片狼藉，真正为社会带来变革的反而是传统行业老兵，用互联网的技术完成数字化转型，凤凰涅槃后重获新生。

马克吐温说：“历史不会重复，只总会押着同样的韵脚”。不要为了智能而智能，更不要强行智能。与其让用户用“对话”形式完成所有工作，不如想办法让用户在现有流程中更高效。你看，虽然大模型的编码能力越来越强，但开发者最喜欢用的还是像 Cursor 这样的编程 IDE。

二、触点：选择用户高频且强感知的场景

在明确了 Agentic 形式之后，我们面临的第二个问题是，要把 AI 集成在系统的哪里？答案很简单，集成在用户的高频且强感知的场景里。

梁宁在《真需求》中描述了如何用「使用频率」、「感知程度」两个维度来识别用户场景，

• 用户使用频率：很多场景会表现出周期性，我们做产品也要尽量选择高频场景。比如为什么京东要入局做外卖，核心就是电商是个相对低频的场景，而外卖则相对高频。你可能一年才买一次数码产品，但可能天天点外卖。

• 用户感知程度：用户对这个场景的优化有没有“体感”，“体感”有多强？就像手机厂商再怎么宣传手机的性能参数，也不如重点打美颜自拍，“照亮你的美”

对于我所负责企业内部的高可用平台，用户使用最高频且强感知的场景就是“处理系统告警”。

三、目标：帮用户完成 ta 的“任务”

理解用户要完成的核心任务，是设计好用 Agent 的关键。克里斯坦森在《创新者的窘境》中提出了著名的"Job to be Done"理论：用户购买产品不是为了拥有产品本身，而是为了"雇佣"这个产品来完成某项特定的工作。这个理论放在 AI Agent 的设计上同样适用——用户使用你的 Agent，本质上是想“雇佣”它来完成自己的某项任务。

就像 Uber 的核心任务不是"提供出租车"，而是"帮用户从 A 点到 B 点"；外卖平台的核心任务不是"送餐"，而是"解决用户的饥饿问题"。同样，我们的高可用平台 Agent 的核心任务也不是"处理告警"，而是"帮助用户快速恢复系统稳定性"。明确了核心任务后，Agent 的设计就有了清晰的方向：

1、如何缩短用户完成工作的步骤？

拿系统告警处理举例，传统的告警处理流程往往冗长：接收告警→查看各种监控指标→分析日志→定位问题→执行修复→验证结果。每个环节都需要用户手动操作，在紧急故障面前，这种流程既耗时又容易出错。

Agent 的价值就在于把这个多步流程压缩成一步操作。当系统告警触发时，Agent 自动拉取相关监控数据、分析异常模式、提供修复建议，甚至在用户确认后直接执行修复操作。用户从原来的“手忙脚乱找问题”变成了“确认 Agent 的诊断和建议”。

这让我想起 iPhone 刚发布时，乔布斯演示如何用手指放大网页的那个瞬间——原来需要键盘快捷键的复杂操作，变成了直觉的手势。好的 Agent 设计也应该有这种“化繁为简”的魅力。

2、主动服务，而非被动响应

更进一步，优秀的 Agent 不应该只是等待用户的指令，而要像一个贴心的助手一样主动发现问题、主动提供帮助。

在我们的实践中，当出现告警任务时 Agent 会主动接手，基于告警内容，结合我们暴露的 MCP Server 主动寻求答案，当用户点开告警任务去处理时，发现 Agent 已经准备好了答案，或已经搜集好了更多的信息，只等开发者决策是扩容还是回滚。

这种主动服务的理念，其实就是把 Agent 从“工具”升级为“伙伴”。用户不再需要记住各种提示词技巧，Agent 会在恰当的时机主动出现，提供恰当的帮助。当 Agent 真正理解了用户要完成的任务，并能够主动、高效地帮助用户达成目标时，才会有“你懂我”的超预期体验。

四、设计系统提示词，而非搭建工作流

Rich Sutton 在《The Bitter Lesson》（苦涩的教训）中写道：70 年的 AI 研究历史告诉我们一个最重要的道理，以来纯粹算力的通用方法，最终总能以压倒性优势胜出。这个观点放在 Agent 设计上同样适用，与其精心设计复杂的工作流，不如相信语言模型的推理能力，用好的系统提示词来引导它。

Anthropic 在《Building Effective Agents》对 Agent 和 Workflow 有着清晰的界定和描述，Workflow 是预定义的步骤序列，适合处理结构化、可预测的任务；而 Agent 则更适合处理开放性、需要推理和决策的复杂场景。很多开发者在构建 Agent 时陷入了一个误区：试图用工作流的思维来设计 Agent，结果做出来的系统既不如工作流稳定，也没有 Agent 的灵活性。

图来自 Anthropic 的博客，Agent 的设计有着简单的美感

在我们的高可用平台实践中，最初的设计思路也是工作流导向的：先判断告警是什么类型，对于单机类问题要如何处理，对于业务指标异常要如何处理，Agent 要按照人类专家经验来做。这种方式看似逻辑清晰，但实际运行中问题重重，不仅要配置难以维护的复杂流程图，还扼杀了 Agent 的灵活性。

在我看到 Cline、Cursor、Devin 的 System Prompt 之后惊讶的发现，这么好用的编程 Agent 竟然没有在系统提示词中写任何编程技巧，它们没有写用 Java 应该如何编程，遇到特定的需求要用什么样的设计模式，只写了目标、能力、能调用的工具列表、工作原则、约束条件。我恍然大悟。

当然，这并不意味着工作流毫无价值。在确定性高、重复性强的场景下，工作流仍然是最优选择。关键是要明确什么时候用 Agent，什么时候用 Workflow。正如 Anthropic 所说：使用最简单、最可靠的方法来完成任务。如果一个简单的工作流就能解决问题，就不要过度设计 Agent；但如果任务需要推理、判断和灵活应对，那就要充分发挥 Agent 的优势。

结语、从“按我说的做”到“你看着办”

做 Agentic 的开发，其实代表着人类与 AI 协作关系的重新定义。在传统软件开发中，产品经理和程序员扮演着“上帝”的角色：我们精确定义每一个功能点，设计每一个交互流程，编写每一行代码逻辑。系统必须严格按照我们的设计意图执行，不允许有任何越界行为。但在 AI 的世界里，我们不再试图穷尽所有可能的场景，而是告诉 Agent：“我有这些工具，面对用户的需求，怎么做你看着办。” 从此，我们不再是 AI 的“指挥官”，而更像是 AI 的“教练”。

这种转变对开发者提出了新的要求。我们需要更深入地理解业务本质，因为只有理解了“为什么”，才能设计出好的系统提示词；需要更敏锐的产品直觉，因为 Agent 的表现很大程度上取决于我们对用户需求的理解；需要更开放的心态，因为 AI 可能会给出我们从未考虑过的解决方案。

在这个 AI Agent 的元年，让我们从“按我说的做”的控制思维，转向“你看着办”的协作思维。相信 AI，但也要引导 AI；放手让 AI 发挥，但也要设定好边界。只有这样，我们才能做出更“好用”的 AI Agent。

---

欢迎关注我的微信公众号，一起探索在 AI 时代的进化之路