别再堆MCP工具了，好用的AI Agent始于一个“懂你”的System Prompt！让Agent从“能干活”变“懂人心”，理解比调用更重要。

发表于 2025-06-01 更新于 2026-05-10

前言：有了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。