Vibe coding 实战:自主规划、能调工具、有记忆的Agent，开发思路全公开 | 大白话科普版

Vibe coding 实战:自主规划、能调工具、有记忆的Agent，开发思路全公开 | 大白话科普版 Vibe coding 实战:自主规划、能调工具、有记忆的Agent，开发思路全公开 | 大白话科普版 Modified August 12, 2025 No access 周末休闲活动策划视频剪辑 首选版 00:00 No access manus 回放 00:00 吴恩达在 Prompt Engineering 课程也有提过：写 prompt 不是“许愿”，而是一个来回磨合、逐步澄清需求的过程。AI 不可能“秒懂你在想什么”，它只能靠你一步步和它对齐你的意图。 所以，Human in the Loop 是刚需，如果没有用户监督，完全交给AI，它就飞了，到头来你会发现它交付的的确满足自己说过的诉求，但就是和自己脑海里的样貌大相径庭。 以本项目为例：用户表示偏好户外活动，但内心实际也接受室内替代。AI 查出当天会有雷暴，这时就面临决策分岔点：是改日期还是改成室内活动还是其他。如果 AI 自作主张，继续策划户外行程，而非及时和用户确认，就有可能吃力不讨好。 也正因如此，我首选“周末休闲活动策划”场景，而非与之类似但更通用的“旅行规划”场景。原因不止是开发复杂度，更关键是控制变量。毕竟一天内的、附近的休闲活动比起多天的、跨地域的旅行，确定性的因素要多得多。虽说伴侣和搭子可能是固定的，但是去哪里、花多少钱、住哪里、怎么去，可有太多的可商量的余地了！ 如果加上多日、多人、跨城的旅行任务，决策条件数量和复杂度暴涨，多个因素交织影响，不仅仅对模型推理能力的要求更高，需要 human 登场干预的次数也要增多（其实也不那么好用了）。 比如如果突然发现目的地当天要举行大型活动、住宿暴涨、景区限流，那整条行程就可能要重排。这时候 AI 该怎么办？自作主张换个地方？推迟出发？改成周边游？每一种应对策略都有代价，也牵涉到用户的真实优先级（是更看重放松，还是不想浪费年假，还是特别想去那个地方）。这些权衡，没法“猜”，只能问。 但凡你对“智能”的预期比较高，那必然 AI 自作主张的成分就高，但如果这件事你让 AI 自作主张的风险比较大，那大概率交付结果就会不符合预期。 AI 编程能力越来越强之后，有些人总想着一句话就让 AI 设计出一个软件，殊不知这其中有多少的细节需要明确，如果完全交给 AI，处处都让它自作主张，交付结果很难让人满意（除非只是玩一玩）。 而且，请注意，以上这些讨论还是在“ AI 的记忆始终在线”的前提下！但更多时候，这样“既要又要也要还要”的多决策条件的多步骤任务，AI 会在上下文理解上卡脖子，忘记了其中部分关键信息。接下来我们就来了解下什么是上下文管理，为啥它很重要。 2. 上下文管理模块的设计 3. 工具调用模块 4. 用户体验设计篇 虽然我是做 UX 出身，但我认为要做好 AI 产品设计，理解底层技术是不可或缺的。 用户的“直觉体验”本质上是对系统能力的一种感知错觉，而这种错觉必须由系统工程主动构建出来的，就好比说ChatGPT其实并没有记忆，但是通过上下文管理系统模拟了记忆机制。 而用户体验设计环节，就是去营造、强化这种“直觉化”的感知错觉，让它更接近用户的生活经验，就好比ChatGPT 用连续的对话流的形式，营造出了AI“存在记忆”的假象。 对于 AI 助手，要让用户觉得靠谱，也需要从生活经验中找答案，我们会认为什么样的真人助理靠谱？ 将过程暴露出来 AI 的规划流程、接下来打算怎么做、用了什么工具推理出什么结论，这些都应该清晰告诉用户。我们应该和用户共享同一个上下文环境，这不仅仅是技术层面的，也是感知层面的（UI 层面），它看到的就是你看到的，你在界面中的操作它也应该要能感知到。 事事有回音 别埋头一直做，憋大招，要及时和用户同步对齐是不是在正确轨道上，如果缺失了关键的信息，需要及时确认，尤其是觉得非常影响后续工作推进的，这样不会忙活儿了半天发现白忙活儿。比如AI调用天气工具发现当天会下雨，就要及时和用户确认，看是不是能接受室内活动，还是说干脆换个日子。 时刻 echo BOSS的需求 比如用户前期有表达过要“排除危险系数高的项目”，AI 在执行任务过程中，会 echo 用户的偏好，让你感觉到“你说的我都听到了，放心吧”。 给足可验证的真实信息 用链接标注出处、完整引用上下文，增加可解释性，才能建立“这个 AI 说得有依据”的信任感——尤其是在帮用户做决策的场景下，这一点不能含糊。 降低BOSS的认知、操作负担 自动获取信息，之前的偏好会被记录、日期、上次填写历史会被保留。 日后如果能接入用户的日历等软件更好，可以了解哪些日程要错开，也可以直接在日历帮用户制定日程。简而言之就是，尽可能把相关的能获取的输入端都用满，能利用上的输出端都用上。 结语 2025 年，大模型在多个维度上已展现出顶尖的智力水平，但要胜任长期执行的智能任务，仍离不开严谨的系统设计。 如何在不抑制智能的前提下让流程可控？如何确保模型始终在轨而不跑偏？如何在不牺牲交付质量的前提下提升效率、降低成本？如何增强用户控制感却不把负担转嫁给用户？ 这些问题早已有人探索，我只是走在一条已有经验指引的路上，试着更深地理解它们、使用它们。越实践，越意识到这条路径还有很大空间值得挖掘。真正稳健、高效、可信赖的 AI 系统，或许仍在形成中，但我们对它的期待，已经开始变得具体。 No access 周末休闲活动策划视频剪辑 首选版 00:00 No access 周末休闲活动策划视频剪辑 首选版 00:00 No access manus 回放 00:00 No access manus 回放 00:00 吴恩达在 Prompt Engineering 课程也有提过：写 prompt 不是“许愿”，而是一个来回磨合、逐步澄清需求的过程。AI 不可能“秒懂你在想什么”，它只能靠你一步步和它对齐你的意图。 所以，Human in the Loop 是刚需，如果没有用户监督，完全交给AI，它就飞了，到头来你会发现它交付的的确满足自己说过的诉求，但就是和自己脑海里的样貌大相径庭。 以本项目为例：用户表示偏好户外活动，但内心实际也接受室内替代。AI 查出当天会有雷暴，这时就面临决策分岔点：是改日期还是改成室内活动还是其他。如果 AI 自作主张，继续策划户外行程，而非及时和用户确认，就有可能吃力不讨好。 也正因如此，我首选“周末休闲活动策划”场景，而非与之类似但更通用的“旅行规划”场景。原因不止是开发复杂度，更关键是控制变量。毕竟一天内的、附近的休闲活动比起多天的、跨地域的旅行，确定性的因素要多得多。虽说伴侣和搭子可能是固定的，但是去哪里、花多少钱、住哪里、怎么去，可有太多的可商量的余地了！ 如果加上多日、多人、跨城的旅行任务，决策条件数量和复杂度暴涨，多个因素交织影响，不仅仅对模型推理能力的要求更高，需要 human 登场干预的次数也要增多（其实也不那么好用了）。 比如如果突然发现目的地当天要举行大型活动、住宿暴涨、景区限流，那整条行程就可能要重排。这时候 AI 该怎么办？自作主张换个地方？推迟出发？改成周边游？每一种应对策略都有代价，也牵涉到用户的真实优先级（是更看重放松，还是不想浪费年假，还是特别想去那个地方）。这些权衡，没法“猜”，只能问。 但凡你对“智能”的预期比较高，那必然 AI 自作主张的成分就高，但如果这件事你让 AI 自作主张的风险比较大，那大概率交付结果就会不符合预期。 AI 编程能力越来越强之后，有些人总想着一句话就让 AI 设计出一个软件，殊不知这其中有多少的细节需要明确，如果完全交给 AI，处处都让它自作主张，交付结果很难让人满意（除非只是玩一玩）。 而且，请注意，以上这些讨论还是在“ AI 的记忆始终在线”的前提下！但更多时候，这样“既要又要也要还要”的多决策条件的多步骤任务，AI 会在上下文理解上卡脖子，忘记了其中部分关键信息。接下来我们就来了解下什么是上下文管理，为啥它很重要。 2. 上下文管理模块的设计 3. 工具调用模块 4. 用户体验设计篇 虽然我是做 UX 出身，但我认为要做好 AI 产品设计，理解底层技术是不可或缺的。 用户的“直觉体验”本质上是对系统能力的一种感知错觉，而这种错觉必须由系统工程主动构建出来的，就好比说ChatGPT其实并没有记忆，但是通过上下文管理系统模拟了记忆机制。 而用户体验设计环节，就是去营造、强化这种“直觉化”的感知错觉，让它更接近用户的生活经验，就好比ChatGPT 用连续的对话流的形式，营造出了AI“存在记忆”的假象。 对于 AI 助手，要让用户觉得靠谱，也需要从生活经验中找答案，我们会认为什么样的真人助理靠谱？ 将过程暴露出来 AI 的规划流程、接下来打算怎么做、用了什么工具推理出什么结论，这些都应该清晰告诉用户。我们应该和用户共享同一个上下文环境，这不仅仅是技术层面的，也是感知层面的（UI 层面），它看到的就是你看到的，你在界面中的操作它也应该要能感知到。 事事有回音 别埋头一直做，憋大招，要及时和用户同步对齐是不是在正确轨道上，如果缺失了关键的信息，需要及时确认，尤其是觉得非常影响后续工作推进的，这样不会忙活儿了半天发现白忙活儿。比如AI调用天气工具发现当天会下雨，就要及时和用户确认，看是不是能接受室内活动，还是说干脆换个日子。 时刻 echo BOSS的需求 比如用户前期有表达过要“排除危险系数高的项目”，AI 在执行任务过程中，会 echo 用户的偏好，让你感觉到“你说的我都听到了，放心吧”。 给足可验证的真实信息 用链接标注出处、完整引用上下文，增加可解释性，才能建立“这个 AI 说得有依据”的信任感——尤其是在帮用户做决策的场景下，这一点不能含糊。 降低BOSS的认知、操作负担 自动获取信息，之前的偏好会被记录、日期、上次填写历史会被保留。 日后如果能接入用户的日历等软件更好，可以了解哪些日程要错开，也可以直接在日历帮用户制定日程。简而言之就是，尽可能把相关的能获取的输入端都用满，能利用上的输出端都用上。 结语 2025 年，大模型在多个维度上已展现出顶尖的智力水平，但要胜任长期执行的智能任务，仍离不开严谨的系统设计。 如何在不抑制智能的前提下让流程可控？如何确保模型始终在轨而不跑偏？如何在不牺牲交付质量的前提下提升效率、降低成本？如何增强用户控制感却不把负担转嫁给用户？ 这些问题早已有人探索，我只是走在一条已有经验指引的路上，试着更深地理解它们、使用它们。越实践，越意识到这条路径还有很大空间值得挖掘。真正稳健、高效、可信赖的 AI 系统，或许仍在形成中，但我们对它的期待，已经开始变得具体。 🔗 mp.weixin.qq.com 点赞 33 分享 65 推荐 12 mp.weixin.qq.com mp.weixin.qq.com 点赞 33 分享 65 推荐 12 mp.weixin.qq.com 2025 被很多人称作 AI Agent 的元年。3 月份 Manus 爆火之后，不少人第一次意识到：原来 AI 真能自己干活。最近，一码难求的 Lovart AI 更是让“Agent 热”再次出圈。 作为一名致力于实践出真知的作者，我尝试用 cursor 独立搭了一个“周末去哪逛”的 AI Agent，可以基于用户需求规划出一个包含行程安排、交通路线规划、场地推荐、预算分配的周末休闲活动方案。 它具有自主规划和思考的能力，以及工具调用的能力，可以搜索小红书帖子、查询天气、规划交通路线、查看场所信息（如大众点评评分、人均消费）等工具，可以自主判断先后使用哪些工具来完成任务，直至获取到所有所需信息，再交付结果。 完整回放(已加速处理) 整个开发过程，我采用了 vibe coding 的理念：通过与 AI 对话，描述需求，AI 生成代码，我再进行测试和优化。这种方式让我能够专注于思考和设计，而不是陷入繁琐的编码细节。在这个过程中，我深刻体会到 vibe coding 所倡导的“放手让 AI 做繁重工作，开发者专注于高层次思考”的理念。 这篇文章，我会完整复盘这个 Agent 从 0 到 1 的关键构建思路，是一次把 AI Agent 用在真实场景中的全流程推演和实践。 • 如果你是感兴趣但没动手过的“Agent潜在玩家”，文章能帮你搞懂构建一个能“自主决策 + 多工具调用 + 拥有记忆能力”的 Agent 的基本工作机制，从而对各类 Agent 的能力边界有个清晰的判断。 • 如果你已经在这个方向上探索，文中的某些关键决策和问题，也许能和你的项目产生一点“思路碰撞”。 文章稍长，建议先收藏慢慢看，相信你能从中带走实用的启发。 1. Agent 的框架选择 流程编排应该交给 AI 吗？ 你要完成一个周末休闲活动策划的任务，必然可拆分为包含多个步骤的流程。关于流程制定，眼下有两条路： • 一条是相信 AI，把任务全权交给它决策、执行，最大程度灵活； • 另一条是相信自己，设计一个固定的工作流，让 AI 按部就班执行，最大程度可控（自动化工作流）。 听起来，第一条路“聪明”但不可控，容易翻车；第二条路“稳定”但死板，灵活性差。怎么选？关键要看流程的动态程度。 像周末休闲活动策划这种非标准、信息动态变化的任务，显然流程是很动态的。例如： • 你刚找到一个活动场所，但一查营业时间发现不合适，需要实时调整计划； • 搜索路径非常发散，可能是泛关键词起手找灵感，也可能是锁定某个具体场所； • 用户反馈五花八门：有的想换活动类型，有的想了解某餐厅的菜品细节，有的想比较多家同类 Spa 店…… 这种场景下，人几乎无法穷举所有分支，固定流程也就很难实现。 那是不是就应该“全交给 AI”？也不行，会导致聪明反被聪明误。 我试过用像 Manus 或 扣子空间这种全自动通用 Agent 做同一个任务，结果发现——在特定场景下，小而专的 Agent 反而效果更稳定。原因很简单： • 关于工具的使用，Manus缺少路线规划的工具、缺乏 POI 地点验证的工具，所有的信息都只能通过浏览器搜索这一种手段来解决，效果可想而知。 • 关于执行的流程，天气好坏是非常影响整个策划的前置考量点，但 Manus 并没有考虑到要优先检查这个重要信息，而是在和用户确认完规划之后，就一股脑执行到最后了。在垂直 Agent 中，我们是可以预设这个要求的。 Manus 执行回放对比：https://manus.im/share/nwhkbCqpDe2rTkZkYgmJlE?replay=1 总结来说，通用 agent 最大的问题不是它理解力差，而在于它： • 框架过于开放 • 缺少必要的工具或可用工具太多，不知道哪一个更合适当前的任务 最后就好像招了一个聪明的但却没有经过上岗培训的实习生，为了完成任务，做了很多事情，看起来非常辛苦，也好像都的确都做了，但是最后就交付给你一个一言难尽的结果。说不上错，但是就是和你的预期有落差。 而垂类 Agent，由于限制到一个边界条件相对封闭、目标清晰、工具集有限的场景下，交付更加稳定。路径简单，反而不容易乱走。 我的做法是：不设死流程，也不全托 AI，而是让 AI 自由行动，但限定它的工具边界和行为框架。重点是：把最需要智能判断的部分交给 AI，其他部分用规则兜底，让它在半开放的“轨道”上运行。 比如，在这个项目里，AI 负责判断： • 当前任务需要哪些工具组合？ • 下一步该做什么？搜索结果够不够？ • 缺了哪些关键信息？要不要提示用户补全？ • 有无信息矛盾或风险？需要不需要跟用户确认？ 与此同时，我用系统提示词设定了一些执行上的“硬规则”： • 必须先规划再动手、首个任务应该查天气、输出最终方案前要参考模板； • 用 POI 工具查场所信息（评分/营业时间等），不能用小红书搜索工具； • 在关键节点（如需求冲突时）必须与用户确认。 还有一种我目前尚未实际尝试，但认为很值得探索的方式，是引入多智能体架构。 任务不是由一个单一的 Agent 包办，而是由一个“中央调度者”将任务拆解后，分配给多个专职的小 Agent 来执行。每个智能体只聚焦一个子任务，比如查天气、搜小红书、处理用户反馈等——术业有专攻，这种拆分方式也更符合软件工程里的单一职责原则，执行更稳定，边界更清晰。 延伸一下，Manus等“通用 Agent”最靠谱的形态可能不是“啥都会做”，而是作为一个调度器存在：当任务来了，它根据上下文和一堆指标（历史表现、用户偏好、任务匹配度等）去选择那个“该上场的”智能体——就像一个 Agent 版的 App Store。这种结构既保留了 AI 的灵活判断力，又通过模块化方式增强了整体的可控性。 一口气完成所有任务，还是中途让用户参与决策？ 在设计任务流时，无论是 AI 自主编排，还是开发者预设流程，都会面临一个根本问题：要不要一口气干到底、一次交付结果？ 实践下来，答案很清楚：别指望一次搞定，复杂任务必须多轮交互。 这不是因为 AI 不够聪明，而是因为人类表达本身就不清晰。用户在描述需求时，往往模糊、含混，很多关键细节没说，也没想清楚，甚至自己也要边做边想。语言天然存在歧义，而歧义在任务中早晚会爆雷。 比如我说“一张A4纸，请你对折再对折”，你可能会这样折： 但实际上AI就能按照另一种方式去对折（你别说，也没错，但是就是和你想得不一样）：