最近我突然开始认真研究豆包和飞书了，这件事情放在我自己身上其实还有点反差，因为过去很长一段时间我都在折腾各种国外的 Agent，Claude Code、Codex、各种 Vibe Coding 工具，包括我自己一直在使用的 Hermes Agent，国内国外五花八门的东西基本上都体验过不少。
因为我自己本身就是程序员出身，所以这些东西用久了之后会有一种很自然的惯性，就是看到一个新的 AI 产品，我第一反应往往不是这个东西普通人拿来能干嘛，而是它支持什么模型，有没有 CLI，MCP 怎么接，Skill 怎么写，能不能调用浏览器，权限怎么处理，上下文有多大，再深入一点就是 Agent Harness、Memory、Workflow 这些东西。
这些内容对我来说很自然，我也一直觉得自己对现在 Agent 的发展方向理解得还算比较深，但是最近重新去看豆包和飞书的时候，我才慢慢发现一个问题：
我可能因为技术了解得太多，反而缺失了一部分普通用户看 AI 的视角。
我想把这个东西叫做“技术的诅咒”。
我身上的技术诅咒
这个问题其实不是最近才存在，只是我以前一直没有意识到。
比如我给别人介绍一个 Agent，很容易上来就讲服务器怎么部署，MCP 怎么配置，Skill 怎么写，AGENTS.md 应该怎么调整，甚至我会天然觉得这些东西都是使用 Agent 的基础知识，因为我自己每天接触的就是这些东西。
但是后面想了一下，绝大部分普通人为什么要知道这些？
一个做行政的人，他可能只是希望一场会议结束之后，AI 能帮他把会议纪要整理出来，然后顺便把待办分给对应的人；一个运营每天有很多文档和数据要处理，他想的可能只是这些重复工作能不能让 AI 帮他做；一个老师或者普通上班族拿到一份几十页的文件，他只是想快速知道里面讲了什么。
他们根本不关心背后到底用了 MCP 还是 Skill，也不会去研究 Agent 为什么能调用这些工具，很多时候他们只是想解决自己现实生活和工作中的需求。
这句话看起来好像很简单，但是我以前其实很容易忽略。
因为我经常去使用 Vibe Coding 相关的 Agent，导致我对编程这一块了解很多，慢慢就会天然地从开发者视角去理解 Agent，好像一个 Agent 就应该有 MCP、有 Skill、有终端、有各种扩展能力。
但是如果把程序员这个身份先拿掉，我后来发现自己其实只研究了 Agent 很小的一块。
我对 Agent 的分层
从我自己的经验出发，我现在更倾向于把市面上的 Agent 产品简单分成三个大板块：
个人、工作和开发。
个人：针对的是日常使用的 Agent，最贴近我们生活的可能就是手机 APP，因为我们可以随时聊天、随时使用 AI，这一块更多保存的是你自己的个人信息、习惯和喜好，对应的就是 GPT 的 Chat，或者说豆包 APP 这种产品。
工作：这部分是我们真正干活的部分，不要单纯把它和“上班”画等号，更多就是把它理解成工作场景。处理报表、整理文档、发送邮件、完成 PPT、开会、协作，这些都是工作的一部分，而且很多时候它已经不只是服务于个人，而是进入了组织或者公司的环境里面，对应的就是现在这些办公 Agent。
开发：这部分就是我最熟悉的 Vibe Coding 了，大部分任务都是开发和编码相关的，写程序、写脚本、改 Bug、操作代码仓库。对于绝大部分普通人来说，这个场景其实并没有那么高频，更多时候可能只是偶尔脑子一热想做个东西出来，但是对于程序员来说，这反而是每天都在接触的。
把这三个分类分下来之后，我才发现自己以前的问题在哪里。
开发这一块我已经研究得太多了，Codex、Claude Code、TRAE 这些东西我长期都在用，所以很多时候已经形成一种肌肉记忆，但是个人和工作这两块，我以前反而没有真正花同样的时间去理解。
而豆包 APP 对应的就是个人，豆包办公和飞书对应的是工作，这也是为什么我这次会反过来认真研究豆包和飞书。
它们刚好补的是我以前最容易忽略的两块。
从豆包和飞书开始重新看 AI
一开始我只是抱着简单了解产品的心态去的，但是越看越发现一个很有意思的事情。
如果单从产品功能的角度去看这些产品，比如豆包、飞书、ChatGPT、Codex、Claude Code 可能看起来完全不是一种东西，甚至可以说是天差地别。
一个是普通人每天聊天的 AI 软件，一个是公司里面或者工作的时候会使用的软件，跟别说那些对于小白来说更复杂的东西了。
但是如果把产品表层的那些干扰因素去掉，只看它们最后想做的事情，你会发现其实都是为了一件事情：
用 Agent 去完成现实世界里的事情。
豆包侵入的是我们个人相关的范围，它会接触你的文件、搜索、浏览器、个人信息和各种日常需求；
飞书侵入的是我们公司或者工作相关的范围，它本身已经拥有文档、消息、会议、表格、知识、组织关系、项目和权限等一系列能力，不再是简单地服务于个人，而是在服务组织或者公司；
TRAE、Codex、Claude Code 侵入的就是开发相关的范畴，因为它们天然就适合看到代码、仓库、Terminal 和整个工程。
但是不要单独去理解它们，因为现实里面这些场景本身就不是完全分开的。
你写代码并不是真的只写代码，一个需求可能最开始来自一份飞书文档，开会确认之后再进入开发，写完代码还要提 PR、处理测试问题、同步进度，最后又会回到办公和协作场景里面。
所以它们可能进入的世界不一样，但是最后都在想办法解决一个问题：
怎么让 AI 知道更多关于你现在所处环境的信息，然后真正帮你做事情。
这其实也是我后面越研究越觉得有意思的地方。
以前我们很容易把 Agent 理解成一个模型加几个工具，但是如果它真的要帮你完成现实世界里面的事情，那它最终一定需要知道更多东西。
你是谁，你现在在干什么，相关资料在哪里，它可以调用什么工具，有什么权限，哪些事情可以自己执行，哪些事情需要找你确认，做完之后结果应该放到哪里。
所以豆包、飞书、Codex、Claude Code 看起来形态完全不同，但是底层其实都在慢慢补类似的东西，只是进入的环境不一样。
一个进入个人，一个进入工作，一个进入开发。
也正是看到这里，我开始理解另外一个以前容易忽略的问题。
越强的 AI，可能反而越不应该让用户感觉到它很复杂
AI 如果想要完成越来越多现实世界里的事情，在我的认知里面觉得，那它背后的系统一定会越来越复杂。
因为它需要更多的东西来作为它干活的基础，更丰富的上下文，更多的工具和记忆这些都是它可以完成工作的基本。但是普通人是不需要理解这么多东西的，因为他们更关心的是结果，中间态是可以消失的。
所以如果是从我的角度看，以后的Agent 不会越来越简单，反而会越来越复杂，因为它对普通人基本上是一个黑盒状态，相对的厂商就需要解决更多的问题，才能达成这个目标。
但是这些复杂的问题不能直接丢给用户去解决，而且做好封装。
以前我这种技术用户很容易觉得一个软件配置越多、自由度越高、能接的东西越多，就代表它越强，但是站在普通用户的角度，每多一个配置项，其实就是多一层理解成本。
我学到的
这次研究的经历，反而让我开始慢慢回归Agent的初心，以前我是背负着“诅咒”在前进，所以我会忽略很多东西，但是现在我发现了不一样的东西。
我把它总结成了两点：
第一点，不管是什么软件还是工具，都需要从你的需求出发，只有你真正需要使用的才是好的软件或者工具，而不是越多越好。能力多了之后，你的维护成本其实也会跟着提高，如果一个功能装上之后半年都没有真正使用过，那很多时候本质上只是技术上的一种自我满足。
第二点，不是什么软件都需要打造得很高级，也不是什么东西都需要从复杂概念开始讲，最终还是要回归到使用者的角度出发，因为不是每个人都会懂得那么多概念，只要能稳定地解决他的问题，那这个 Agent 对他来说就是有用的。
以后学东西，还是要多角度的去看待，不能管中窥豹只看见了一部分，也可能人家设计简单只是表层，更深层次原因需要你自己慢慢体会了。
