AI Agent很容易在演示里显得聪明。用户写一句目标，屏幕上连续出现思考、搜索和调用工具，最后得到一份结果。产品真正上线以后，问题会落到更具体的地方。它拿什么数据，能改哪些东西，卡住以后怎样告诉用户，已经做过的动作能不能查到。
所以Agent的最小版本要围绕一项完整任务来定。选一个有明确开始和结束的场景，让用户能够判断结果是否有用。任务太宽，团队会把时间花在补能力。任务太轻，一次普通问答就能完成，Agent没有承担实际工作。
一个合适的MVP任务通常具备两个条件。用户现在已经在重复做它，完成后能检查结果。先让这项任务跑通，再考虑多Agent协作、长期记忆和更复杂的自动化。
先写清谁把什么交给Agent
用户角色要具体到工作情境。运营人员整理一周反馈，销售人员为明天的会议准备客户摘要，创始人把访谈笔记变成待验证的问题，这些任务都能看见输入和结果。写成提升效率或帮助决策，团队很难知道第一版该接什么数据。
接着找出用户目前怎样完成这件事。他打开哪些页面，复制哪些内容，在哪一步需要判断，最后把结果交给谁。Agent需要接住其中最费时间、也最适合检查的一段。其余步骤可以先保留人工处理。
Agent与固定工作流怎样选
步骤稳定、输入字段明确的任务，用普通工作流通常更可靠。每次都要根据材料选择下一步，或需要从多个工具里挑一个时，Agent才有更明显的价值。这个判断会影响成本、测试量和用户对结果的信任。
步骤可以提前写死，规则明确，结果容易复现，适合表单处理和标准通知。
需要读材料、选择工具或根据中间结果调整下一步，执行路径会随任务变化。
让Agent负责理解和选择，把付款、发布、写入数据库等关键动作交给确定的流程。
第一版要接真实工具和数据
静态样例能帮助团队讨论界面，无法验证产品能不能工作。Agent要完成核心任务，至少要接通必要的数据源或工具。权限不足、字段缺失、接口超时和返回内容变化，都会影响用户体验。
数据接入以后，界面要把来源和时间交代清楚。用户需要知道Agent看到了哪些材料，哪些内容没有拿到。结果里如果包含推断，也要让它与已有事实分开。这样用户才能决定接下来是接受、修改，还是回到原始材料。
写操作要留在人手里
发送消息、修改客户记录、发布内容和付款都会影响外部世界。第一版可以让Agent准备动作，在执行前展示目标、内容和影响，再让用户确认。这个确认不是多余的一步，它让团队更容易发现理解偏差，也给用户保留控制。
确认页还应说明能否撤回。能够撤回的动作，完成后给出入口。不能撤回的动作，在确认前把范围写得更清楚。Agent若需要连续执行多个外部动作，最好拆成可以检查的阶段。
失败路径要与成功路径一起设计
工具调用失败以后，只显示请重试，用户很难判断刚才发生了什么。产品要保存已完成的步骤，说明停在哪里，并给出继续、修改输入或转人工的选择。重复执行可能造成副作用时，系统还要避免同一动作被再次提交。
显示正在读取什么、准备做什么，以及哪一步需要用户决定。
保留输入、工具返回、用户确认和最终动作，方便复盘与纠错。
用真实任务判断MVP是否成立
测试时准备一组真实任务，包含正常输入、缺少信息和工具失败。记录用户在哪一步接管，哪些结果被修改，任务最后有没有完成。模型回答看起来顺畅，只能说明演示读起来不错。用户愿意把任务交给它，并且能处理失败，才说明产品开始站住。
验证通过以后再扩能力。下一项功能应当来自已经出现的阻塞，例如用户反复补同一种资料，或每次都在同一处人工接管。这样扩出来的路线会比功能清单更接近真实需求。