Agent是这两年大模型领域最热的方向，但市面上关于“Agent产品经理”的讨论，大多还停留在“要有技术背景”“要懂大模型原理”这类通用建议上。真正把一个Agent产品从Demo推到生产环境，面对的是完全不同的产品逻辑——你设计的不是一个功能，而是一种“行为”。用户不关心它背后用了什么模型，只关心它能不能稳定地帮我把事办成。这个差别，从根本上改变了产品经理的工作方式。
先有一个经常被忽视的认知：做Agent产品和做SaaS产品，需求工程的方式不一样。传统SaaS产品里，用户提一个需求，你把它翻译成功能规格说明书，研发照着做，测试照着测，上线之后用户满意。这是个线性流程。Agent产品里，用户提一个需求，你不能直接把它翻译成“让AI做这件事”。因为你没法精确控制AI怎么做，你只能控制它被允许使用哪些工具、在什么约束下运行、遇到什么情况需要停下来问人。本质上你设计的是一个“决策框架”，而不是一个“执行路径”。一个典型的例子是：客户说要一个“能自动处理退款”的Agent，传统PM会去设计退款流程的每一步操作，Agent PM需要回答的是：什么情况下Agent可以自主发起退款，什么情况下必须转人工，退款金额超过多少需要二次确认，失败重试几次后应该停止。这些问题不是功能设计，是规则设计。一个好的Agent产品经理，脑子里装的不是“这个功能怎么做”，而是“这个Agent在什么边界内可以自主行动，什么情况下必须把控制权交还给用户”。产品经理的产出不是一份PRD，而是一套行为准则。
第二个容易被低估的是“持续校准”这个能力。传统产品上线之后，PM的工作就转到下一个版本了。Agent产品上线之后，只是开始。模型的输出永远有不确定性，今天表现良好，明天换了新版本可能就出现偏移。你没法像修bug一样修Agent，因为很多问题不是“代码写错了”，而是“模型在这个场景下的判断不符合预期”。这个时候产品经理得能判断：这是一个需要调整Prompt的问题，还是需要修改工具调用逻辑，还是需要重新设计整个任务拆解方式？生产环境里，Agent的行为会随着数据积累和模型更新持续演变，PM要能持续校准它的行为边界。那些习惯把产品上线就甩手的PM，在Agent领域会非常不适应。这里没有“做完”这个状态，只有“还在跑”这个状态。
第三个维度的挑战更隐蔽也更关键：评估。传统产品改一个按钮颜色，可以做A/B测试看点击率。Agent产品没法这样测。一个Agent的行为是链式的——前面一步的输出决定后面一步的输入，中间任何一个环节的偏差都可能被放大。你改了一个Prompt，可能修复了A场景的问题，但B场景的准确率从95%掉到了60%。要在一个星期里找出这种问题，靠人工测试根本不可能覆盖。所以Agent产品经理必须有能力设计自动化的评估体系——构建覆盖主要场景的测试集，建立自动化回归机制，把“今天Agent的表现有没有变差”这件事从“凭感觉”变成“看数据”。更重要的是，你得能判断哪些指标能真正反映用户体感。Token消耗、任务完成率、用户修正次数——这些数字比模型跑分更能说明Agent在生产环境里的真实表现。
最后一个维度是“人机边界”的设计能力。Agent做得再好，也一定会有处理不了的场景。一个好的Agent产品，不是在所有场景下都硬撑，而是在知道自己搞不定的时候优雅地把任务交给人类。产品经理需要想清楚：什么时候该让Agent自主行动，什么时候必须停下来等人确认，什么时候该把完整上下文转给人工客服。这个边界的设定，既要考虑用户体感，也要考虑技术可行性，还要权衡成本和风险。它没有标准答案，只能靠产品经理对用户场景和技术能力的双重理解来持续调优。
说到底，做生产级Agent的产品经理，本质上不是在设计功能，而是在定义一套行为准则——告诉Agent“你可以做什么”“你不可以做什么”“遇到什么情况该问人”。然后围绕这套准则建立持续校准和自动评估的体系，确保Agent在生产环境里越跑越稳。这比写PRD难得多，也比写PRD有意思得多。
