一、缘起：为什么世界需要另一个 AI Agent ？
1. 从 ChatGPT 到 AutoGPT：AI 工具的进化
最开始接触 AI 时，我只是把 ChatGPT 当作一个聊天机器人。到后来又用上了 Cline 、Windsuf 、Cursor 这类 AI 编程工具。起初不太习惯不怎么去用，但习惯了之后发现，这些工具用起来是挺爽的。比如，用 Cline 和 Cursor 直接对话就可以快速定位和修复代码问题，脑子不在线的时候直接提需求‘你要 XXXXXX’，然后等着结果就行。我可以信不过 AI ，但我可以信得过测试用例和运行结果，渐渐的AI 不再只是对话，而是逐渐成为工作流的一部分，不想动脑子的时候就不动脑子，直接提需求就行，然后 TAB 、TAB 、TAB ，done 。
2. 传统行业的痛点：Excel 、手写单据和低效协作
我的上一份工作是做物流行业的信息系统。这个行业里，很多人还在用 Excel 、手写单据、打印 PDF 、手动录入数据——效率低得让人抓狂。曾经，我花了三个月写了个 Mac/iOS 的 OCR 工具，想帮他们自动提取表格数据。虽然效果不错，但考虑到物流从业者大多用 Windows 和 Android ，市场覆盖率太低，就放弃了。
3. 内心的激动：是时候让 AI 来解决这些枯燥的重复劳动了
再后来，GPT-4 刚出来的时候我测试了 GPT-4 的多模态能力，让它解析 PDF 和图片里的表格数据——结果远超预期。我就想如果给 AI 一对翅膀，让 AI 不仅能“看懂”文件，还能“操作”软件，工作方式会被彻底改变。
2025 年 2 月，公司裁员我领了大礼包。“说人话+自动化”再次点燃了我的热情，按捺不住心中的悸动“现在不做，回头就只有看别人做好的了“， ”just do it”！
让 AI 长上翅膀和手脚吧
二、构建：在理想与现实之间走钢丝
1. 产品定位的迷茫
最开始，我并没有想清楚 Swiflow 到底要服务谁。只是觉得“说人话+自动化”很酷。为了验证想法，我在朋友的数据库上跑了个用例：让 AI 根据媒体资讯自动生成研究报告。
效果很好——即使没有数据字典的辅助，AI 也能自己查询分析表结构、查询数据、输出报表构建看起来不错的分析。
这个正向反馈让我开心了好一阵子，但问题也随即而来：我开发的是桌面端应用，大多数用户根本没有数据库可用。
“酷炫效果”不等于“实用产品”，只能继续从桌面场景找具体用例。
2. 功能取舍
第一版 Swiflow 内置了几个核心工具：
- 文件操作（文本读写） 命令行工具（执行脚本）数据库工具（数据查询）浏览器自动化（网页搜索）
浏览器工具让我纠结了很久：“到底该支持哪些操作？” 点击？输入？滚动？还是直接模拟用户行为？
越想越复杂，最后意识到：“先解决一个具体问题，别妄想做‘全能 Agent’。”
3. 技术踩坑
在这个项目之前我没做过真正的 Autonomous Agent （自主智能体），只写过自动回复邮件的 Bot 。
但完全自动化的 Agent 复杂程度远超预期——原本乐观估计一两个月搞定，结果光是 MVP 就花了俩月，中间还不停从开源项目（ Cline 、Sono 、Open Manus ）中学习经验，有时候忍不住问自己为什么要自己造轮子，开车不香么。
感谢开源组织，好人一生平安
问题 1：Prompt 像豆腐渣工程
初始 Prompt 是基于别的项目改的，只做了简单约束，结果 AI 经常“自由发挥”——要么误解需求，要么生成不靠谱的代码。
问题 2：多轮对话崩盘
用户提问：“将这个目录下的 PDF 单据整理成表格。”
Agent 响应：写 Python 脚本→装依赖→调整环境→修改报错→再错再改……
出发了很久，还没走出高老庄。
问题 3：上下文爆炸由上可以看出 AI 是个老好人，不会拒绝你，也不会拒绝你做的事。在 Agent 里正是如此‘我错了，我要改’，‘让我再试试’，‘我还能行，扶我起来’。但 Agent 每执行一步都会往对话里塞更多信息，而且不停试错不停改，很快就把上下文窗口撑爆了。
Agent 勤奋且努力，我半夜醒来都觉得自己不如 Agent 努力，忍不住想说‘扶我起来我还能行’。
问题 4: 造工具不靠谱最初没有经验，以为 python 的轮子那么多了，让 agent 随便造呗，给你 100 块钱想吃啥买啥
等实际测试时发现，agent: '你让我自己做饭么？'，'是的，你自己做饭'，'好的，请放心'
最后：'MAMA ，房子被烧了'
由于让 Agent 自己搓工具靠不住，最终决定还是先用现成的吧。于是迅速拥抱 MCP 生态，先解决工具链的稳定性问题。
饿肚子的时候吃外卖也挺好的，预制菜不预制菜的重要么？
三、顿悟：Agent 开发中的反常识
1. “全能 Agent ”是幻觉
测试时，Swiflow 玩五子棋、写贪吃蛇、解数独——表现惊艳。但一遇到真实工作场景（比如“物流单据转 Excel”），效果就大打折扣。
后来我懂了：AI 有知识，但没经验 它知道“表格”是什么，但它不懂“物流行业的单据长啥样”，也不懂每个字段之间的业务关系。这个问题也不是一个复杂的问题，本可以调整 Prompt 来优化，但整个流程中“发现问题→修改 Prompt →重新对话”的循环太不友好。于是，我加入了“记忆功能”——用户只需在对话中提醒 Agent “记住这个、记住那个”，它就能逐步学习业务规则。
2. Agent 需要适时"踩刹车"
传统软件开发是"输入→处理→输出"，但 Agent 更像是概率性的探索。如果完全放手让它自己跑，很容易南辕北辙。在合适的地方适当的停下来咨询用户的意见也是个不错的选择，像 Cursor 的 Agent 就经常这么干不知道是为了省 token 还是为啥。
3. "完全自主"是个美丽的陷阱
最初我希望 Swiflow 能"完全自主"——用户说一句话，AI 就能独立完成整个任务。但现实给了我当头一棒：
- 输入输出比例失衡：用户输入 10 个字，AI 可能输出 1000 字，交互效率极低 错误会累积放大：一步走错，后面全歪，越跑越偏 缺乏反馈机制：用户不知道 AI 在干什么，AI 也不知道自己做得对不对
所以现在的思路是：与其信马由缰，不如相敬如宾 —— 让 AI 成为"会主动汇报的助手"，而不是"全权代理的黑盒"。
四、成果：从理想主义到实用主义
经过半年的摸爬滚打，Swiflow （swiflow.cc）现在具备了一些实用的核心功能：
- 支持自定义 Prompt：用户可以随意更改 Prompt ，定制属于自己的工作流支持记忆功能：Agent 能记住重要信息，只需说"请记住我们刚才沟通的结论"MCP 协议支持：通过 MCP Server 扩展 Agent 能力，让功能更强大支持定时任务：可以设置"每半小时帮我检查一下最新邮件"这样的定时任务支持多 Agent：为不同任务设置专门的 Agent ，避免上下文混乱
在实际应用中，它能稳定处理批量文件处理、数据格式转换、邮件管理、信息收集等桌面自动化任务。虽然离最初"AI 万能助手"的愿景还有距离，但至少在具体场景下，它确实能帮用户省下不少时间。
更重要的是，这个过程让我对 AI Agent 有了更现实的认知：它不是魔法，而是工具。就像任何工具一样，关键在于找到合适的使用场景，而不是期待它解决所有问题。
五、 结语
做 Swiflow 的半年里，我的体会是：虽然 AI Agent 还不完美，但大模型的快速进化和 Agent 在某些场景下的优异表现，让未来值得期待。也许某一天，我们真的可以直接委托 AI Agent 撒手去做了，我们就吃着火锅唱着歌，事儿就办成了。
如果你也想体验一下这种"撒手掌柜"的感觉，欢迎来试试 Swiflow——说不定真能让你提前下班去吃火锅呢。
