「0天复刻Manus」的背后，这名95后技术人坚信：“通用Agent一定存在，Agent也有Scaling Law”| 万有引力-CSDN博客

嘉宾 | 范文栋

对话 | 唐小引

责编 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

今年 3 月，Manus 的横空出世，引爆了新一轮的 AI Agent 热潮。

人们惊讶地发现，原本复杂繁琐的任务流，如今一个 Agent 就能自动规划、调用工具、执行操作，甚至还能主动 Debug 和自我修复——生成式 AI 从“语言理解”向“任务执行”演化，Agent 也不再是只能聊天的大语言模型，而是可以“动手做事”的数字助手。

然而，在这场技术热潮中，质疑与分歧也接踵而至：“Agent 的 Scaling Law 是否存在”、“通用 Agent 是否真的可行”，这些问题引发了广泛的争议与探讨。一方面，部分研究者坚信，随着模型技术的进步，Agent 将能实现从特定任务向通用能力的跨越；而另一方面，也有声音指出，所谓的“通用 Agent”，或许只是一套被过度期许的工程幻象。

为了解答这些技术争议，由 CSDN 主办的《万有引力》栏目在全球机器学习技术大会的现场特别邀请到了 CAMEL AI 核心成员，CAMEL、OWL 开源项目核心开发者和维护者范文栋。作为一个 96 年出生、从开源社区一路走到前沿 Agent 工程一线的年轻技术人，范文栋参与了从 CAMEL、OWL 等多个项目，也亲历了这一波 Agent 技术从探索到爆红的全过程。那么接下来，就让我们在 CSDN &《新程序员》执行总编、《万有引力》主理人唐小引的主持下，看看范文栋眼中的 Agent 未来将如何发展？

AI 产品爆发，但你的痛点解决了吗？8.15-16 北京威斯汀·全球产品经理大会 PM-Summit，3000+ AI 产品人社群已就位。
直面 AI 落地难题、拆解头部案例、对接精准资源！

扫码登记信息，添加小助手进群，抢占 AI 产品下一波红利：

进群后，您将有机会得到：
· 最新、最值得关注的 AI 产品资讯及大咖洞见
· 独家视频及文章解读 AGI 时代的产品方法论及实战经验
· 不定期赠送 AI 产品干货资料和秘籍

以下为对话内容（为方便阅读，进行了适当的文本优化）：

“0 天复刻 Manus”的 OWL，十天斩获 1w+ Star

唐小引：我们今天将围绕「如何构建 AI Agent」以及「开发 Agent 背后的技术故事与人物」展开分享。文栋，先和大家打个招呼吧，也介绍一下你最近负责的开源项目？

范文栋：大家好，我是范文栋，CAMEL-AI 的核心贡献者，也是 Eigent AI 的技术负责人（Tech Lead）。

相信大家都知道，前阵子有个叫 Manus 的项目很火。而我们 CAMEL 社区此前发布了一个名为 OWL 的开源项目，它在权威评测榜单 GAIA Benchmark 上曾位列第一，是最强的开源 Agent 之一。当时，我们打出了“0 天复刻”的口号，好像这个项目很快就做出来了，但其实有点标题党——之所以能如此快速发布 OWL，是因为我们过去已经做过相应的工作，才能快速迭代。

其实，CAMEL 做 Agent 已经两年了。可能很多人都不知道，CAMEL 框架是在 23 年 3 月推出的，也是世界上第一个多智能体框架，所以其实我们已经有了两年的积累。当 Manus 项目出来以后，我们看到 CAMEL 框架中已有的模块能够非常快速地复现类似能力，所以就很快地推出了 OWL 这个框架。

唐小引：我看到有小伙伴把文栋的项目名字发出来了，不过拼写上有点小误。我来大致梳理一下这个背景：前段时间，大家应该对通用 Agent 项目 Manus 有印象。Manus 是一个闭源项目，它的核心作者季逸超曾表示，未来可能将 Manus 开源，但截至目前我们还没有看到正式发布的开源版本。

当时，Manus 的邀请码异常紧缺，可谓一码难求。正是在这个背景下，我们看到了开源社区的力量：包括文栋所在的 CAMEL AI 团队，以及 MetaGPT 团队，都在极短的时间内完成了对 Manus 的开源复现，并将项目发布到了 GitHub 上。其中，文栋团队推出的就是 OWL 项目。

范文栋：是的，OWL 作为一个开源项目，在推出以后受到了大量社区开发者的关注与反馈，我们也根据这些意见进行了多轮迭代和优化。当然，OWL 在推出之初的整体成熟度确实不如 Manus，毕竟是一个在短时间内完成的项目。

但我们构建 OWL 的初衷，也并不是要和 Manus 去比拼产品化能力，而是希望能为开发者提供一个真正开源、可拓展的基础框架，让大家能基于 OWL 去做二次开发和构建，例如结合自身业务需求，去构建更加深入的使用场景和应用。

唐小引：可以跟大家分享一下 OWL 项目开源之后的情况吗？我记得当时社区反响非常热烈，你们在开源 OWL 之后应该特别忙，可以讲讲你们收到的社区反馈和那段时间的心路历程吗？

范文栋：当时我们项目刚上线，仅十天时间就在 GitHub 上获得了一万个 Star，吸引了大量开发者的关注。这个数字甚至都反超 CAMEL 了。要知道，作为第一个多智能体框架，CAMEL 积累了两年的 Star 数，在短短十天内就被 OWL 超越，也说明了大家对这个方向的高度关注。

那段时间，很多人加入了我们的社区，反馈非常多，GitHub 上也出现了大量 Issue。我那时还跟团队的小伙伴开玩笑说，我每天醒来都要多当五六个小时的客服，消息根本回不过来。大家在刚开始使用 OWL 时，确实可能会遇到各种问题，比如与模型部署相关的操作，或者海外 API 使用不便等等。当时，我们在几天内就关闭了 GitHub 上 200 多个 Issue，不过这还只是 GitHub 上的，微信群里的反馈更多，保守估计能有上千、甚至上万个。

唐小引：在 GitHub 上，有没有哪些让你印象深刻的反馈或者 PR 提交？

范文栋：OWL 项目刚上线的时候，它还是一个只能通过本地 IDE 运行的形态，并没有 Web App，所以使用起来不是那么方便，尤其是对于刚开始接触 Agent 开发的小伙伴来说。随后，我们团队就开发了一个 Web App，虽然初期版本还不够成熟，但得到了社区的积极反馈。例如，有开发者提交了改进 UI/UX 的 PR，帮我们优化了整体的交互体验。

现在的 Web App 虽然还有提升空间，但相比刚上线时已经有了很大进步。这也充分体现了开源社区的力量，大家都非常踊跃地提交 Issue、贡献 PR，帮助项目不断完善。

唐小引：那现在 OWL 的迭代工作，主要是你们团队在做，还是已经可以依靠社区的力量，由更多开发者提交 PR，而你们主要负责代码审核和合并？

范文栋：对，没错。OWL 刚推出的时候，我们把一些 Open Issue 放在 GitHub 主页，现在项目底部也仍然保留了一部分。当时社区响应非常快，我们有时会一次性发布三五个 Issue，十几分钟就会有开发者在下方留言“认领”，并提交相应的贡献。

前段时间，我们的主要工作就是在社区中回复各种 Issue 和用户问题，同时把一些希望新增的功能以 Issue 的形式加在 README 中。开发者认领之后，我们会主动联系他们并提供一些支持，包括代码审查等。

唐小引：有没有哪些比较关键的迭代可以和大家分享？或者说，OWL 是否有类似 OpenManus 那样的 Roadmap，对后续方向有一定的规划？

范文栋：有的，我们在 OWL 刚上线时就进行了整体重构。第一版 OWL 是基于 CAMEL 的 RolePlaying 模块开发的一个版本，叫 OWL RolePlaying。当时，我们希望它能在 GAIA Benchmark 上取得好成绩，所以整体调教非常注重性能，可在实际使用中用户会发现资源消耗很高：为了确保任务顺利完成，中间会进行一些重复验证，导致 Token 消耗偏高。

所以，后来我们进行了一些更平衡的设定和优化。如果大家想体验性能最强的版本，可以切换到 GAIA-58.18 这个分支；而 Main 分支并非性能最优版本，但胜在成本控制和稳定性，整体更加均衡。这是我们前段时间一个比较重要的更新。

另一个比较核心的是 OWL Agent 使用工具的更新。例如 Browser 工具，它允许 Agent 打开浏览器，执行自动化任务，目前这一模块还在持续迭代中。此外，Terminal 工具也是非常重要的更新，它支持 Agent 调用终端，自主安装依赖库并执行代码。我们更新完 Terminal Tool Kit 后做了一个测试：让这个 Agent 自行安装一个处理 PDF、Slides 相关的库，然后再让 Agent 独立生成一个 PPT，它也很好地完成了任务。

关于 OWL 的 Terminal Tool Kit，其实还有一个故事。很早以前，我们的 Founder 李国豪（CAMEL-AI.org社区创始人）就在 GitHub 的 Roadmap 里写下了这个 Tool Kit——那时甚至连模型的工具调用功能都还没完善，但他当时就判断 Terminal 工具会是一个非常强大的能力。不过这个事情大家之前都没有意识到，直到后来 OWL 和 Manus 受到广泛关注以后，我们才发现这个工具原来真的那么强。

“为爱发电”走入开源社区，最终全职投身 Agent 研发

唐小引：接下来，我们来聊聊“人”的故事。文栋是国豪推荐给我的，我最开始就问：“文栋是哪年出生的？”因为我发现现在 AI 圈里很多核心开源项目的主创都非常年轻，像文栋你就是 1996 年出生，是非常典型的一位新生代代表。

所以文栋，可以请你跟大家分享一下你的成长经历吗，比如你是如何走上 AI 这条技术路线的？以及，了解到你是远程工作，你和 CAMEL AI 团队现在的协作方式又是怎样的？

范文栋：好的，我先介绍一下我是怎么一步步从接触 AI 走到现在的。

我本科读的是一个比较传统的工科专业，并非计算机相关。记得我大二那年，正值 AlphaGo 刚刚推出，我当时在看直播，看到最后 AlphaGo 战胜李世石，那一刻给我带来了极大的震撼——原来 AI 可以做到这种程度，连人类顶尖智慧也能被挑战。从那时起，我开始对 AI 产生浓厚兴趣。

研究生阶段，我转向了和算法相关的统计学，并选修了大量计算机相关课程，也开始从事 NLP 相关的研究。之后，我在爱尔兰中央统计局实习，主要负责文本分类。当大语言模型横空出世时，我又受到了二次震撼，觉得这个技术太厉害了。

在爱尔兰中央统计局工作一段时间后，因为疫情、气候等各种原因，后来我选择了回国，并加入了巴斯夫中国数字化中心，担任 AI 工程师，主要工作是给销售、市场、生产、供应链等业务线开发 AI 解决方案。不过，在大企业内部，新技术的推进节奏通常较慢。

当 2023 年初生成式 AI 兴起时，我内心非常激动。当时我在团队中承担了一个利用生成式 AI 撰写市场宣传文案的项目，也让我对这一方向产生了更深的兴趣。我还利用业余时间，用 GPT 的 API 复现了一个我曾经苦战七个月的文本分类项目——仅用半天时间就完成了，准确率还更高。

从那之后，我便主动寻找一些与生成式 AI 相关、有技术挑战的项目。我一开始用的是 LangChain，因为在前公司中也是用它做开发。但后面我逐渐意识到 LangChain 的一些局限性，例如抽象层次较多，修改起来也不太方便。

所以，我就开始寻找一些有意思的开源项目，因为我觉得开源才是能快速迭代技术能力、学到很多东西的地方。机缘巧合下，我在小红书上看到了国豪。他说他当时也看到了我发的一篇吐槽 LangChain 的帖子，就主动私信我。他给我发了 CAMEL 的项目链接，我看到那个熟悉的骆驼 Logo 才想起来之前见过，但没有深入了解。而和国豪联系上之后，我开始仔细研究 CAMEL 的代码，发现这实在是一个非常酷的项目。

当时我刚接触 Agent，对它的认知还停留在传统的生成式 AI 应用层面，比如用 LangChain 调用模型完成自然语言生成。但当时 CAMEL 已经实现了多智能体之间的协同，可以用两个 Agent 来完成一个复杂任务。我觉得这个东西太酷了，于是开始以志愿者身份在业余时间参与 CAMEL 的开发。后来，随着对项目的投入越来越深，关系也越来越紧密，我最终决定在去年辞职，全职加入了 CAMEL AI 团队。

唐小引：也就是说，你最开始是在开源社区中，是作为一个对项目非常感兴趣的个人贡献者参与进来的？

范文栋：对，一开始就是单纯的“为爱发电”。直到现在，我的这份热爱还在。

唐小引：我能从你身上感受到技术人所具备的那种自我驱动精神——Just for fun，就像 Linux 之父 Linus Torvalds 提倡的那样，这也是开源社区最有魅力的地方。那现在 CAMEL AI 团队大概有多少人？团队的规模和大家的分布情况是怎样的？据我了解，国豪现在人在伦敦。

范文栋：我们团队的规模其实还比较小，也很年轻，成立至今仅一年左右。目前整个团队大约有 20 多人，这其中还包含了不少实习生和兼职，真正的全职成员只有五位。

核心团队的人员分布也非常广，我们还曾说自己是“日不落团队”：有人在英国伦敦，有人在美国，还有人在澳大利亚，在印度和中国也都有一些小伙伴，涵盖了全球很多主要时区。因此，我们的协作方式基本上是远程线上为主。

我们的核心成员，大多都是从社区中转化过来的开源贡献者，比如我自己。此外，我们也在与很多高校的博士生和研究人员展开合作，希望通过这种方式接触到更多非常优秀、且对 Agent 感兴趣的小伙伴，一起去探索和推动这个领域的进展。

探索“Agent Scaling Law 是否存在”的实践

唐小引：能和大家分享一下你在全球机器学习技术大会上的演讲内容吗？你的演讲主题是“从工具到自主化，构建更强大的 Agent 系统”，那么从“工具”走向“自主化”，这条路径的技术挑战和整体思路是怎样的？

范文栋：我这次的演讲主要围绕我们正在研究的一个方向——Agent Scaling Law。我们都知道，模型的 Scaling Law 对应的是模型的参数量、训练数据等。而在 Agent 系统中，我们提出了一个类比性的假设：Agent 的数量是否可能也像模型参数那样，成为系统能力提升的关键因素？关于这一点，我们 CAMEL 也在 Agent 里探索着去构建环境与模拟系统等等。

唐小引：所以，你们是已经发现 Agent 中确实存在类似于 Scaling Law 的现象了吗？

范文栋：还不能这么说。我们目前还处在探索阶段，不能断言 Agent Scaling Law 一定成立。但我们确实在实验中看到了多智能体的能力比单个智能体要强。比如我们之前在 CAMEL 的研究论文里也提过，在超过 70% 的任务场景中，采用两个 Agent 协作的 RolePlaying 框架，任务完成效果明显要优于仅用一个 Agent 的。

唐小引：那你们团队在探索 Agent Scaling Law 的实践过程中，有哪些关键性的发现或经验可以和大家分享？

范文栋：首先是刚才提到的 Agent 数量。我们之前参与发布了一个名为 OASIS 的项目，它是一个以大模型为基座的通用社会模拟平台，支持多达 100 万个 Agent 进行交互，我们通过支持大规模 Agent 的模拟来开展社会模拟研究。例如，在 X 或 Reddit 等海外社交平台场景中，当部分 Agent 发表意见后，其他 Agent 会受到何种影响。

另外是环境相关的内容。以刚才提到的 OWL 项目为例，我们让 Agent 能够获取当前浏览器上的信息并执行操作。实际上，在这之前我们还有一个名为 CRAB 的项目，它是一个跨端项目，可在本地 PC 和手机上执行操作，这也是全球首个此类项目。当时，我们还做了一些 Benchmark 来评估多模态模型的能力。

还有一个我们近期比较专注的方向：利用 Agent 生成合成数据。我们认为多智能体系统的构建基于单个智能体，单个智能体的核心在于模型本身，而模型的底层支撑则是数据。因此，我们希望从底层出发，通过提升数据质量来反哺多智能体系统。具体而言，我们可利用 Agent 生成高质量的合成数据，并在 Agent 系统中结合环境和验证器等，以提升整体数据的生成质量。

唐小引：你刚才提到了当前 AI 圈非常关注的几个 Agent 关键命题，其中一个是：Agent 是否存在 Scaling Law。我记得，此前智谱在发布 AutoGLM 时曾明确表示，他们在构建 Agent 系统的过程中发现了 Scaling Law。那从你的观察来看，目前国内外在做 Agent 开发时，是否已经在这一问题上形成了共识，还是大家仍处于探索期？

范文栋：我个人认为，目前大家整体上还是处于探索阶段，还没有形成非常强的一致性共识。不同的团队、研究者可能会有不同的看法。

唐小引：那为什么智谱会明确提出 Agent 存在 Scaling Law？

范文栋：可能每个人都有自己的看法。当然，我个人也相信 Agent 是有 Scaling Law 的。

唐小引：你平时除了在 CAMEL AI 团队工作之外，会关注其他团队的相关项目吗？有没有哪些和你们方向比较相似或完全不同的？

范文栋：我目前大多数时间还是主要投入在 CAMEL 项目的开发中，所以像智谱的 AutoGLM，我其实没有非常深入地了解。不过，我也会定期关注一些其他多智能体框架的进展。

唐小引：如今 AI 圈内，都在探索从单智能体到多智能体系统的发展，但不少人指出多智能体面临着很多困难并难以突破。那么，基于你对多智能体的观察以及CAMEL AI 团队实践的情况，有什么可以分享的吗？

范文栋：确实，在多智能体系统的开发过程中，有很多工程层面和研究层面的复杂问题，还可能涉及诸如成本控制等多个维度，许多环节都需要进行深度优化。

从技术角度来说，搭建一个多智能体系统并不难，但要做得好其实很难——几乎每个模块都要去做优化。比如，Agent 之间的协作机制、任务调度策略、工具调用流程及 Agent 本身的记忆系统等，要想把这些方面都优化到极致，肯定要花很多功夫。

唐小引：你刚才提到，“要做得好其实很难”，这个难度主要体现在哪些方面？你们 CAMEL AI 团队在这方面的核心实践又是如何展开的？

范文栋：我打个比方。比如在工具调用方面，很多人最直观的做法是：将所有可能被 Agent 调用的工具，全部添加进 Tool List，然后转换为 OpenAI 的 Schema，再交由大语言模型去完成工具调用。但实际上，从成本与效益的角度来看，这里有很多优化空间。比如，在把所有工具“一股脑”地提供给 Agent 之前，可以先通过语义检索的方式来筛选工具。如果希望进一步优化效果，也可以对用于搜索的 Embedding 模型进行微调。甚至，你也可以对整个模型进行微调，让它变成一个在特定工具调用场景下非常强的模型。

还比如在代码生成方面，如果我们希望让 Agent 去写代码，其效果很大程度上取决于大模型本身的训练数据质量。假设大模型已经接触过大量 NumPy、Pandas 这类成熟库的使用样例，那它生成相关代码可能效果不错；但如果要让它写一些非常小众的库，可能就写不出来了。这时，就需要结合这些小众库的数据，对模型进行针对性的微调。

在我们的设想中，一个合理的多智能体系统，不应该是所有 Agent 共享一个统一的大模型。当然，理论上也可以使用像 Claude 4 这样非常强大的模型来统一处理所有任务，但成本非常高。对于许多简单任务，其实只需使用小参数量的专家模型即可高效完成。所以我们认为，未来的演进方向应该是：不同任务由不同的 Agent 负责，每个 Agent 背后对接不同、特定的模型，每个 Agent 还会接入专属的工具和知识库，以此形成一个更加分工明确、组合灵活、成本可控的 Agent 生态。

“我个人觉得，通用 Agent 一定是存在的”

唐小引：既然谈到了模型和工具，让我想起了 Manus 最早爆火的时候，也引发了大家对于 Anthropic 在去年发布的 MCP 的广泛关注。不过我之前一直有点困惑，因为 Manus 作者明确表示他们并没有使用 MCP，但 MCP 却因为 Manus 火了。我之前查看 OpenManus 的项目源码时，发现其中有涉及 MCP 的相关开发，不知道 OWL 这边的情况是怎样的？

范文栋：我们在刚推出 OWL 时，其实并没有集成 MCP，但在项目上线后的第五天左右，就加入了对 MCP 的支持。MCP 是一个协议，它的最大价值在于：开发者可以通过 MCP 非常方便地接入 MCP 生态系统中已有的各种工具和服务，这是一个非常好的生态。

大家都知道，做 Agent 开发时要接入很多第三方工具，需要做很多适配和重复的开发工作，把一个工具适配到另一个框架里。而 MCP 作为统一协议，就很好地解决了这个问题。

目前，我们 CAMEL AI 团队也在积极拥抱 MCP 生态，计划将 CAMEL 内部已经实现的 40 多种常用工具（如搜索、地图、天气等相关功能），全部装进一个 MCP Server 中，方便大家去做外部调用。

唐小引：那从本质上来说，MCP 和 Agent 之间的关系是怎样的？

范文栋：MCP 更多是偏向模型层的一个设计，但由于 Agent 也是基于模型层的，因此也能从中受益。它最大的优势在于：提供了一套统一的协议和接口，极大简化了 Agent 的开发流程，开发者无需重复造轮子，即可非常便捷地调用外部那些已接入的 MCP Server。

唐小引：今年年初开始，业内有不少声音提出：2025 年将成为“千 Agent、万 Agent 大战”的一年。大家不仅在呼唤通用机器人，也在热议通用 Agent 的可能性。但关于通用 Agent 是否存在，这其实是一个存在争议的话题。以 AI Coding 为例，很多人认为通用的 Coding Agent 很难真正实现，可能更像是一个美好的幻想。那么，围绕这个争议和“通用 Agent”这个话题，你有哪些观点可以分享吗？

范文栋：首先，大家确实可以看到在过去一两年里，市面上陆续涌现出大量的 Agent 平台，但不同平台的切入点有所不同。例如 MetaGPT 更聚焦在 AI Coding领域，通过多智能体协作完成完整的软件开发流程，是一个相对垂直的方向。

而 CAMEL 的定位则更偏向于通用性。我们把 CAMEL 定义为一个通用多智能体框架，虽然我们并没有针对某些特定的业务场景去深挖，但我们所构建的工程体系和实践经验，都为后续的垂直拓展打下了坚实基础——开发者可以用 CAMEL 结合自己的业务领域去做拓展。

我个人觉得，通用 Agent 一定是存在的。就拿 AI 编码来说，像 Devin、Cursor 等成功的 Coding Agent 已经证明了通用能力的可行性。这些智能体背后的关键技术通常包括 RAG，也就是让 Agent 通过检索已有的代码片段，理解上下文后生成新代码，再整合回当前开发环境。简单来说就是这么一个流程，但它背后依赖的技术也是通用的：就是 Agent + RAG 这一套。

随着 2025 年 Agent 生态的爆发，我们可能会看到越来越多的垂直 Agent 项目，但是通用 Agent 一定会作为底层基础设施而长期存在，并存在着广泛的优化空间。

唐小引：MCP 因 Manus 而迅速走红，甚至 OpenAI 的 Agent SDK 也支持了 MCP。随后，虽然 Google 也加入了 MCP 的支持行列，但它还推出了自己的 A2A（Agent-to-Agent）协议。在此之前，很多人认为 MCP 可能会成为行业标准，尤其是考虑到许多国内的大公司也在采纳 MCP。然而，随着 Google A2A 的推出，现在大家都在比较 MCP 和 A2A，试图评估两者间的竞争态势。那么从 OWL 的视角来看，Google 的 A2A 是否对 OWL 构成了助力呢？

范文栋：MCP 和 A2A 在本质上的切入点有所不同。MCP 已经由 Anthropic 成功占据了一个生态位，而 Google 可能希望通过 A2A 建立自己的生态系统。对于任何一种协议而言，其真正价值在于是否拥有足够的参与者和一个繁荣的生态环境。如果一个协议参与的人不多、声音不够大，它的实际应用价值和影响力也比较有限。

相比之下，A2A 更侧重于统一 Agent 之间的接入范式。无论是对于 OWL 还是 CAMEL 而言，我们都认为这种生态是非常好的，并且也在积极支持 A2A。

一份面向开发者的经验总结

唐小引：听你刚才的分享，我特别有感触的一点是，AI 技术更迭太快、太容易“过时”了。有些技术发展很快，比如 AlphaGo 就深深影响了一代人；但也有不少技术还没真正大火就已经“过时”了。像 LangChain，可能有段时间很火，但很多人还没学透就已经意识到它的局限性了。而如今，也有人说传统的 RAG 已经过时，现在是 Agentic RAG 大行其道的时候。

那么作为一个 AI 从业，在学习新技术这件事上，你有没有一些想法可以分享？

范文栋：AI 的迭代确实非常快。就拿 LangChain 来说，它目前也在不断迭代，推出了 LangSmith、LangGraph 等新模块。当然，我自己还没有花太多时间去深入研究这些更新。

作为开发者，我认为最核心的一点是要保持充分的学习能力，其次是要有非常强的接纳新事物的能力。另外，当一个新的框架或理念出现时，我们也要有一定的辨别能力。有时候一个新 Concept 看起来热度很高，实际上不一定有真实价值，可能只是市场营销的结果。

这种情况下，我们要去了解它底层的原理，判断它的实际作用，再结合整个技术趋势来决定是否值得投入时间去深入学习。如果值得，你就应该沉下心来认真研究。只有这样，我们才能不断迭代自己的技术体系，让自己一直站在这个 AI 浪潮的前沿。

唐小引：今年被称为“Agent 的一年”，对于广大开发者，尤其是与你年龄相仿或更年轻的 00 后开发者来说，如果他们希望投身于 Agent 领域并开展相关开发工作，你有哪些经验或建议可以分享？

范文栋：对于刚入门的学习者来说，我认为从事 Agent 开发，首先应该了解其底层机制，而不是一开始就使用高度抽象化的框架。尽管我们本身也是构建 Agent 框架的团队，但我还是建议开发者从模型层面入手，理解模型是如何执行工具调用、记忆系统的工作原理等基础内容，一步步地去学习。如果一开始你就直接依赖高度抽象的框架，可能会在后续想要深入优化或拓展功能时遇到瓶颈。

另外，我知道大家现在用 AI Coding的能力非常强，都在用一些 AI IDE 写代码。但我建议大家在使用这些 IDE 写代码的时候，要“知其所以然”。对于某些你不理解的代码片段，一定要去问人，或者问这些 Agent 让它解释清楚。千万不要像最近比较火的“Vibe Coding”——让 Agent 写完代码后，只要程序能跑通就不深究。长此以往，反而会对你的技术成长产生负面影响。

唐小引：你自己是什么时候开始接触编程的？

范文栋：我敲代码应该是在读本科的时候，刚开始学的是C 语言，太难了。

唐小引：那你读本科到现在有几年了？

范文栋：差不多十年左右了。

唐小引：哪怕 96 年的开发者，到现在也有十年编程经验了啊？

范文栋：不过本科的时候，开发强度很低，只是为了完成学业。而且那时候学的语言也比较古早，现在也没怎么用到。后来学 Python，才开始用得比较多。

唐小引：那现在 OWL 的代码，有哪些是 AI Coding 来的？

范文栋：CAMEL 做得比较早，那时候 AI Coding 还没那么兴起，很多代码都是手敲的。但是随着项目的发展，我们陆续加入了一些 AI 辅助功能后，我个人大约有超过 80% 的代码是通过 AI 生成的。不过生成之后，我会花大量时间进行代码审查，因为 AI 生成的代码，质量需要你自己去把控，而我修改的量大概在 20% 左右。

唐小引：你现在日常已经很习惯和 AI Coding 工具一起结对编程了吗？

范文栋：对，我现在非常习惯这种方式。如果现在去掉 AI Coding 工具，让我自己手写，我可能会有点手足无措。

唐小引：但即便如此，你还是会把 AI 生成的代码详细地去看，并进行代码审查，对吧？

范文栋：是的。因为 AI Coding可以做好局部某个点的代码生成，但如果面对的是结构复杂、层级较多的系统代码，AI 往往难以理解上下文的完整性，那它给出的可能只是一个局部最优解，而不是全局最优解。

唐小引：听了文栋的经验分享，我发现即便是 96 年的开发者，也在不断探索与实践的过程中积累了丰富的经验，都值得我们借鉴与学习。最后，感谢文栋带来的精彩分享！

范文栋：好，谢谢大家。