一个文件夹，几份Markdown，一台2014年的MacBook Pro。这就是Swyx的生产环境——他跑了三周，完成了数百个任务，月成本0美元。而市面上所有人都在抢的LangChain、CrewAI、向量数据库，他一个都没用。
「当你调用agent.run(task)时，魔法发生了。然后你要穿越五层抽象去调试——为什么我的Agent订了去火星的机票。」
Swyx的 confession 像一盆冷水。他不是反对技术，是反对用复杂度掩盖判断力缺失。Agent系统的硬问题从来不是基础设施，而是决策本身：该发这篇文章还是重写？该优化SEO还是写新工具？
「无栈」架构：用文件系统替代全家桶
他的目录结构简单到近乎粗暴：
~/.workbuddy/ 下面三个文件夹：memory存长期记忆和每日日志，skills放能力扩展的Markdown，automations用TOML文件做定时任务。没有RAG管道，没有嵌入模型，没有编排器。
每个skill就是一份Markdown，里面写清楚：这个能力是什么、什么时候调用、输入输出格式。Agent读文件、写文件、调用API，完事。
这种设计的核心假设是：单用途Agent不需要通用框架。你的Agent如果只做一件事——比如监控GitHub issue、生成内容、自动化部署——那么向量检索、多轮对话管理、工具注册表都是噪音。
Swyx算过账：框架帮你省了200行代码，但当你要debug时，得同时理解框架的抽象层、编排器的调度逻辑、工具注册表的匹配规则。代价是认知债务。
什么时候该上「重武器」
他列了三条红线：
规模化服务。千级用户、多样化需求，这时候状态管理、持久化、向量搜索才变成真需求。但Swyx的界定很毒：这叫「带AI组件的SaaS产品」，不叫Agent。
安全敏感。Agent控制真金白银或真实系统时，审计日志、速率限制、访问控制缺一不可。他自己的agent-exchange项目就用Deno KV，不是因为酷，是因为必须。
跨组织协作。不同公司的Agent需要互相发现、通信，A2A、MCP这类协议才有合法性。这是标准该出现的地方，不是个人自动化工具该抄的作业。
「但读这篇文章的人，大多数在做的不是这些。」Swyx的判断很直接——个人自动化、内容管道、开发者工具，一个文本文件夹够用。
文本即接口：为什么Markdown够用了
Agent的判断逻辑，本质上是文本处理：读上下文、做决策、写结果。Swyx的长期记忆存在MEMORY.md里，每日日志按日期命名，skills用自然语言描述能力边界。
这种设计有个副产品：可解释性。当Agent做了奇怪决策，他打开文件就能追踪完整路径。没有黑箱，没有「框架内部状态」。
对比向量数据库的方案：你把记忆切成碎片、嵌入、索引，检索时靠相似度猜测相关性。Swyx的质疑是——如果你的上下文本来就够小、够结构化，为什么要付这个税？
他的每日日志是线性增长的，但Agent只读最近N天。长期记忆是手工维护的，因为「我是谁、我做过什么」本来就不该每天变。这种「懒惰设计」省掉了整个检索 pipeline。
行业正在犯的错：把SaaS架构抄给个人
Swyx的观察指向一个现象：基础设施供应商需要卖复杂度。向量数据库、Agent框架、编排平台，它们的商业模式建立在「你可能会需要」之上。
但个人开发者和早期团队的真实需求被放大了。你不需要为「未来可能的一万用户」预支架构债务，就像你不需要为「可能去南极」现在买羽绒服。
他的8GB老Mac是个刻意选择——如果方案在这台机器上跑不动，说明它太重了。这个约束倒逼出极简设计：直接API调用、本地文件IO、无状态脚本。
「交易理解力换取便利」是框架的隐性成本。当你用LangChain的agent.run()时，你放弃了对决策链的完整掌控。Swyx的替代方案是显式代码：每一步读什么文件、调什么API、写什么结果，全部摊开。
这种风格不适合所有人。如果你团队有10个后端工程师，维护自定义Agent栈可能是浪费。但如果你是一个人或小团队，框架的抽象层反而成了认知负担的源头。
Swyx最后留了个问题：你的Agent真的需要那个向量数据库吗？还是你只是觉得「别人都在用」？
热门跟贴