「0天复刻Manus」的背后，这名95后技术人坚信：“通用Agent一定存在，Agent也有Scaling Law”| 万有引力
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
嘉宾|范文栋
对话|唐小引
责编|郑丽媛
出品|CSDN（ID：CSDNnews）
今年3月，Manus的横空出世，引爆了新一轮的AIAgent热潮。
人们惊讶地发现，原本复杂繁琐的任务流，如今一个Agent就能自动规划、调用工具、执行操作，甚至还能主动Debug和自我修复——生成式AI从“语言理解”向“任务执行”演化，Agent也不再是只能聊天的大语言模型，而是可以“动手做事”的数字助手。
然而，在这场技术热潮中，质疑与分歧也接踵而至：“Agent的ScalingLaw是否存在”、“通用Agent是否真的可行”，这些问题引发了广泛的争议与探讨。一方面，部分研究者坚信，随着模型技术的进步，Agent将能实现从特定任务向通用能力的跨越；而另一方面，也有声音指出，所谓的“通用Agent”，或许只是一套被过度期许的工程幻象。
为了解答这些技术争议，由CSDN主办的《万有引力》栏目在全球机器学习技术大会的现场特别邀请到了CAMELAI核心成员，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
唐小引：我们今天将围绕「如何构建AIAgent」以及「开发Agent背后的技术故事与人物」展开分享。文栋，先和大家打个招呼吧，也介绍一下你最近负责的开源项目？
范文栋：大家好，我是范文栋，CAMEL-AI的核心贡献者，也是EigentAI的技术负责人（TechLead）。
相信大家都知道，前阵子有个叫Manus的项目很火。而我们CAMEL社区此前发布了一个名为OWL的开源项目，它在权威评测榜单GAIABenchmark上曾位列第一，是最强的开源Agent之一。当时，我们打出了“0天复刻”的口号，好像这个项目很快就做出来了，但其实有点标题党——之所以能如此快速发布OWL，是因为我们过去已经做过相应的工作，才能快速迭代。
其实，CAMEL做Agent已经两年了。可能很多人都不知道，CAMEL框架是在23年3月推出的，也是世界上第一个多智能体框架，所以其实我们已经有了两年的积累。当Manus项目出来以后，我们看到CAMEL框架中已有的模块能够非常快速地复现类似能力，所以就很快地推出了OWL这个框架。
唐小引：我看到有小伙伴把文栋的项目名字发出来了，不过拼写上有点小误。我来大致梳理一下这个背景：前段时间，大家应该对通用Agent项目Manus有印象。Manus是一个闭源项目，它的核心作者季逸超曾表示，未来可能将Manus开源，但截至目前我们还没有看到正式发布的开源版本。
当时，Manus的邀请码异常紧缺，可谓一码难求。正是在这个背景下，我们看到了开源社区的力量：包括文栋所在的CAMELAI团队，以及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运行的形态，并没有WebApp，所以使用起来不是那么方便，尤其是对于刚开始接触Agent开发的小伙伴来说。随后，我们团队就开发了一个WebApp，虽然初期版本还不够成熟，但得到了社区的积极反馈。例如，有开发者提交了改进UI/UX的PR，帮我们优化了整体的交互体验。
现在的WebApp虽然还有提升空间，但相比刚上线时已经有了很大进步。这也充分体现了开源社区的力量，大家都非常踊跃地提交Issue、贡献PR，帮助项目不断完善。
唐小引：那现在OWL的迭代工作，主要是你们团队在做，还是已经可以依靠社区的力量，由更多开发者提交PR，而你们主要负责代码审核和合并？
范文栋：对，没错。OWL刚推出的时候，我们把一些OpenIssue放在GitHub主页，现在项目底部也仍然保留了一部分。当时社区响应非常快，我们有时会一次性发布三五个Issue，十几分钟就会有开发者在下方留言“认领”，并提交相应的贡献。
前段时间，我们的主要工作就是在社区中回复各种Issue和用户问题，同时把一些希望新增的功能以Issue的形式加在README中。开发者认领之后，我们会主动联系他们并提供一些支持，包括代码审查等。
唐小引：有没有哪些比较关键的迭代可以和大家分享？或者说，OWL是否有类似OpenManus那样的Roadmap，对后续方向有一定的规划？
范文栋：有的，我们在OWL刚上线时就进行了整体重构。第一版OWL是基于CAMEL的RolePlaying模块开发的一个版本，叫OWLRolePlaying。当时，我们希望它能在GAIABenchmark上取得好成绩，所以整体调教非常注重性能，可在实际使用中用户会发现资源消耗很高：为了确保任务顺利完成，中间会进行一些重复验证，导致Token消耗偏高。
所以，后来我们进行了一些更平衡的设定和优化。如果大家想体验性能最强的版本，可以切换到GAIA-58. 18这个分支；而Main分支并非性能最优版本，但胜在成本控制和稳定性，整体更加均衡。这是我们前段时间一个比较重要的更新。
另一个比较核心的是OWLAgent使用工具的更新。例如Browser工具，它允许Agent打开浏览器，执行自动化任务，目前这一模块还在持续迭代中。此外，Terminal工具也是非常重要的更新，它支持Agent调用终端，自主安装依赖库并执行代码。我们更新完TerminalToolKit后做了一个测试：让这个Agent自行安装一个处理PDF、Slides相关的库，然后再让Agent独立生成一个PPT，它也很好地完成了任务。
关于OWL的TerminalToolKit，其实还有一个故事。很早以前，我们的Founder李国豪（CAMEL-AI. org社区创始人）就在GitHub的Roadmap里写下了这个ToolKit——那时甚至连模型的工具调用功能都还没完善，但他当时就判断Terminal工具会是一个非常强大的能力。不过这个事情大家之前都没有意识到，直到后来OWL和Manus受到广泛关注以后，我们才发现这个工具原来真的那么强。
“为爱发电”走入开源社区，最终全职投身Agent研发
唐小引：接下来，我们来聊聊“人”的故事。文栋是国豪推荐给我的，我最开始就问：“文栋是哪年出生的？”因为我发现现在AI圈里很多核心开源项目的主创都非常年轻，像文栋你就是1996年出生，是非常典型的一位新生代代表。
所以文栋，可以请你跟大家分享一下你的成长经历吗，比如你是如何走上AI这条技术路线的？以及，了解到你是远程工作，你和CAMELAI团队现在的协作方式又是怎样的？
范文栋：好的，我先介绍一下我是怎么一步步从接触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的开发。后来，随着对项目的投入越来越深，关系也越来越紧密，我最终决定在去年辞职，全职加入了CAMELAI团队。
唐小引：也就是说，你最开始是在开源社区中，是作为一个对项目非常感兴趣的个人贡献者参与进来的？
范文栋：对，一开始就是单纯的“为爱发电”。直到现在，我的这份热爱还在。
唐小引：我能从你身上感受到技术人所具备的那种自我驱动精神——Justforfun，就像Linux之父LinusTorvalds提倡的那样，这也是开源社区最有魅力的地方。那现在CAMELAI团队大概有多少人？团队的规模和大家的分布情况是怎样的？据我了解，国豪现在人在伦敦。
范文栋：我们团队的规模其实还比较小，也很年轻，成立至今仅一年左右。目前整个团队大约有20多人，这其中还包含了不少实习生和兼职，真正的全职成员只有五位。
核心团队的人员分布也非常广，我们还曾说自己是“日不落团队”：有人在英国伦敦，有人在美国，还有人在澳大利亚，在印度和中国也都有一些小伙伴，涵盖了全球很多主要时区。因此，我们的协作方式基本上是远程线上为主。
我们的核心成员，大多都是从社区中转化过来的开源贡献者，比如我自己。此外，我们也在与很多高校的博士生和研究人员展开合作，希望通过这种方式接触到更多非常优秀、且对Agent感兴趣的小伙伴，一起去探索和推动这个领域的进展。
探索“AgentScalingLaw是否存在”的实践
唐小引：能和大家分享一下你在全球机器学习技术大会上的演讲内容吗？你的演讲主题是“从工具到自主化，构建更强大的Agent系统”，那么从“工具”走向“自主化”，这条路径的技术挑战和整体思路是怎样的？
范文栋：我这次的演讲主要围绕我们正在研究的一个方向——AgentScalingLaw。我们都知道，模型的ScalingLaw对应的是模型的参数量、训练数据等。而在Agent系统中，我们提出了一个类比性的假设：Agent的数量是否可能也像模型参数那样，成为系统能力提升的关键因素？关于这一点，我们CAMEL也在Agent里探索着去构建环境与模拟系统等等。
唐小引：所以，你们是已经发现Agent中确实存在类似于ScalingLaw的现象了吗？
范文栋：还不能这么说。我们目前还处在探索阶段，不能断言AgentScalingLaw一定成立。但我们确实在实验中看到了多智能体的能力比单个智能体要强。比如我们之前在CAMEL的研究论文里也提过，在超过70%的任务场景中，采用两个Agent协作的RolePlaying框架，任务完成效果明显要优于仅用一个Agent的。
唐小引：那你们团队在探索AgentScalingLaw的实践过程中，有哪些关键性的发现或经验可以和大家分享？
范文栋：首先是刚才提到的Agent数量。我们之前参与发布了一个名为OASIS的项目，它是一个以大模型为基座的通用社会模拟平台，支持多达100万个Agent进行交互，我们通过支持大规模Agent的模拟来开展社会模拟研究。例如，在X或Reddit等海外社交平台场景中，当部分Agent发表意见后，其他Agent会受到何种影响。
另外是环境相关的内容。以刚才提到的OWL项目为例，我们让Agent能够获取当前浏览器上的信息并执行操作。实际上，在这之前我们还有一个名为CRAB的项目，它是一个跨端项目，可在本地PC和手机上执行操作，这也是全球首个此类项目。当时，我们还做了一些Benchmark来评估多模态模型的能力。
还有一个我们近期比较专注的方向：利用Agent生成合成数据。我们认为多智能体系统的构建基于单个智能体，单个智能体的核心在于模型本身，而模型的底层支撑则是数据。因此，我们希望从底层出发，通过提升数据质量来反哺多智能体系统。具体而言，我们可利用Agent生成高质量的合成数据，并在Agent系统中结合环境和验证器等，以提升整体数据的生成质量。
唐小引：你刚才提到了当前AI圈非常关注的几个Agent关键命题，其中一个是：Agent是否存在ScalingLaw。我记得，此前智谱在发布AutoGLM时曾明确表示，他们在构建Agent系统的过程中发现了ScalingLaw。那从你的观察来看，目前国内外在做Agent开发时，是否已经在这一问题上形成了共识，还是大家仍处于探索期？
范文栋：我个人认为，目前大家整体上还是处于探索阶段，还没有形成非常强的一致性共识。不同的团队、研究者可能会有不同的看法。
唐小引：那为什么智谱会明确提出Agent存在ScalingLaw？
范文栋：可能每个人都有自己的看法。当然，我个人也相信Agent是有ScalingLaw的。
唐小引：你平时除了在CAMELAI团队工作之外，会关注其他团队的相关项目吗？有没有哪些和你们方向比较相似或完全不同的？
范文栋：我目前大多数时间还是主要投入在CAMEL项目的开发中，所以像智谱的AutoGLM，我其实没有非常深入地了解。不过，我也会定期关注一些其他多智能体框架的进展。
唐小引：如今AI圈内，都在探索从单智能体到多智能体系统的发展，但不少人指出多智能体面临着很多困难并难以突破。那么，基于你对多智能体的观察以及CAMELAI团队实践的情况，有什么可以分享的吗？
范文栋：确实，在多智能体系统的开发过程中，有很多工程层面和研究层面的复杂问题，还可能涉及诸如成本控制等多个维度，许多环节都需要进行深度优化。
从技术角度来说，搭建一个多智能体系统并不难，但要做得好其实很难——几乎每个模块都要去做优化。比如，Agent之间的协作机制、任务调度策略、工具调用流程及Agent本身的记忆系统等，要想把这些方面都优化到极致，肯定要花很多功夫。
唐小引：你刚才提到，“要做得好其实很难”，这个难度主要体现在哪些方面？你们CAMELAI团队在这方面的核心实践又是如何展开的？
范文栋：我打个比方。比如在工具调用方面，很多人最直观的做法是：将所有可能被Agent调用的工具，全部添加进ToolList，然后转换为OpenAI的Schema，再交由大语言模型去完成工具调用。但实际上，从成本与效益的角度来看，这里有很多优化空间。比如，在把所有工具“一股脑”地提供给Agent之前，可以先通过语义检索的方式来筛选工具。如果希望进一步优化效果，也可以对用于搜索的Embedding模型进行微调。甚至，你也可以对整个模型进行微调，让它变成一个在特定工具调用场景下非常强的模型。
还比如在代码生成方面，如果我们希望让Agent去写代码，其效果很大程度上取决于大模型本身的训练数据质量。假设大模型已经接触过大量NumPy、Pandas这类成熟库的使用样例，那它生成相关代码可能效果不错；但如果要让它写一些非常小众的库，可能就写不出来了。这时，就需要结合这些小众库的数据，对模型进行针对性的微调。
在我们的设想中，一个合理的多智能体系统，不应该是所有Agent共享一个统一的大模型。当然，理论上也可以使用像Claude4这样非常强大的模型来统一处理所有任务，但成本非常高。对于许多简单任务，其实只需使用小参数量的专家模型即可高效完成。所以我们认为，未来的演进方向应该是：不同任务由不同的Agent负责，每个Agent背后对接不同、特定的模型，每个Agent还会接入专属的工具和知识库，以此形成一个更加分工明确、组合灵活、成本可控的Agent生态。
“我个人觉得，通用Agent一定是存在的”
唐小引：既然谈到了模型和工具，让我想起了Manus最早爆火的时候，也引发了大家对于Anthropic在去年发布的MCP的广泛关注。不过我之前一直有点困惑，因为Manus作者明确表示他们并没有使用MCP，但MCP却因为Manus火了。我之前查看OpenManus的项目源码时，发现其中有涉及MCP的相关开发，不知道OWL这边的情况是怎样的？
范文栋：我们在刚推出OWL时，其实并没有集成MCP，但在项目上线后的第五天左右，就加入了对MCP的支持。MCP是一个协议，它的最大价值在于：开发者可以通过MCP非常方便地接入MCP生态系统中已有的各种工具和服务，这是一个非常好的生态。
大家都知道，做Agent开发时要接入很多第三方工具，需要做很多适配和重复的开发工作，把一个工具适配到另一个框架里。而MCP作为统一协议，就很好地解决了这个问题。
目前，我们CAMELAI团队也在积极拥抱MCP生态，计划将CAMEL内部已经实现的40多种常用工具（如搜索、地图、天气等相关功能），全部装进一个MCPServer中，方便大家去做外部调用。
唐小引：那从本质上来说，MCP和Agent之间的关系是怎样的？
范文栋：MCP更多是偏向模型层的一个设计，但由于Agent也是基于模型层的，因此也能从中受益。它最大的优势在于：提供了一套统一的协议和接口，极大简化了Agent的开发流程，开发者无需重复造轮子，即可非常便捷地调用外部那些已接入的MCPServer。
唐小引：今年年初开始，业内有不少声音提出：2025年将成为“千Agent、万Agent大战”的一年。大家不仅在呼唤通用机器人，也在热议通用Agent的可能性。但关于通用Agent是否存在，这其实是一个存在争议的话题。以AICoding为例，很多人认为通用的CodingAgent很难真正实现，可能更像是一个美好的幻想。那么，围绕这个争议和“通用Agent”这个话题，你有哪些观点可以分享吗？
范文栋：首先，大家确实可以看到在过去一两年里，市面上陆续涌现出大量的Agent平台，但不同平台的切入点有所不同。例如MetaGPT更聚焦在AICoding领域，通过多智能体协作完成完整的软件开发流程，是一个相对垂直的方向。
而CAMEL的定位则更偏向于通用性。我们把CAMEL定义为一个通用多智能体框架，虽然我们并没有针对某些特定的业务场景去深挖，但我们所构建的工程体系和实践经验，都为后续的垂直拓展打下了坚实基础——开发者可以用CAMEL结合自己的业务领域去做拓展。
我个人觉得，通用Agent一定是存在的。就拿AI编码来说，像Devin、Cursor等成功的CodingAgent已经证明了通用能力的可行性。这些智能体背后的关键技术通常包括RAG，也就是让Agent通过检索已有的代码片段，理解上下文后生成新代码，再整合回当前开发环境。简单来说就是这么一个流程，但它背后依赖的技术也是通用的：就是Agent+RAG这一套。
随着2025年Agent生态的爆发，我们可能会看到越来越多的垂直Agent项目，但是通用Agent一定会作为底层基础设施而长期存在，并存在着广泛的优化空间。
唐小引：MCP因Manus而迅速走红，甚至OpenAI的AgentSDK也支持了MCP。随后，虽然Google也加入了MCP的支持行列，但它还推出了自己的A2A（Agent-to-Agent）协议。在此之前，很多人认为MCP可能会成为行业标准，尤其是考虑到许多国内的大公司也在采纳MCP。然而，随着GoogleA2A的推出，现在大家都在比较MCP和A2A，试图评估两者间的竞争态势。那么从OWL的视角来看，Google的A2A是否对OWL构成了助力呢？
范文栋：MCP和A2A在本质上的切入点有所不同。MCP已经由Anthropic成功占据了一个生态位，而Google可能希望通过A2A建立自己的生态系统。对于任何一种协议而言，其真正价值在于是否拥有足够的参与者和一个繁荣的生态环境。如果一个协议参与的人不多、声音不够大，它的实际应用价值和影响力也比较有限。
相比之下，A2A更侧重于统一Agent之间的接入范式。无论是对于OWL还是CAMEL而言，我们都认为这种生态是非常好的，并且也在积极支持A2A。
一份面向开发者的经验总结
唐小引：听你刚才的分享，我特别有感触的一点是，AI技术更迭太快、太容易“过时”了。有些技术发展很快，比如AlphaGo就深深影响了一代人；但也有不少技术还没真正大火就已经“过时”了。像LangChain，可能有段时间很火，但很多人还没学透就已经意识到它的局限性了。而如今，也有人说传统的RAG已经过时，现在是AgenticRAG大行其道的时候。
那么作为一个AI从业，在学习新技术这件事上，你有没有一些想法可以分享？
范文栋：AI的迭代确实非常快。就拿LangChain来说，它目前也在不断迭代，推出了LangSmith、LangGraph等新模块。当然，我自己还没有花太多时间去深入研究这些更新。
作为开发者，我认为最核心的一点是要保持充分的学习能力，其次是要有非常强的接纳新事物的能力。另外，当一个新的框架或理念出现时，我们也要有一定的辨别能力。有时候一个新Concept看起来热度很高，实际上不一定有真实价值，可能只是市场营销的结果。
这种情况下，我们要去了解它底层的原理，判断它的实际作用，再结合整个技术趋势来决定是否值得投入时间去深入学习。如果值得，你就应该沉下心来认真研究。只有这样，我们才能不断迭代自己的技术体系，让自己一直站在这个AI浪潮的前沿。
唐小引：今年被称为“Agent的一年”，对于广大开发者，尤其是与你年龄相仿或更年轻的00后开发者来说，如果他们希望投身于Agent领域并开展相关开发工作，你有哪些经验或建议可以分享？
范文栋：对于刚入门的学习者来说，我认为从事Agent开发，首先应该了解其底层机制，而不是一开始就使用高度抽象化的框架。尽管我们本身也是构建Agent框架的团队，但我还是建议开发者从模型层面入手，理解模型是如何执行工具调用、记忆系统的工作原理等基础内容，一步步地去学习。如果一开始你就直接依赖高度抽象的框架，可能会在后续想要深入优化或拓展功能时遇到瓶颈。
另外，我知道大家现在用AICoding的能力非常强，都在用一些AIIDE写代码。但我建议大家在使用这些IDE写代码的时候，要“知其所以然”。对于某些你不理解的代码片段，一定要去问人，或者问这些Agent让它解释清楚。千万不要像最近比较火的“VibeCoding”——让Agent写完代码后，只要程序能跑通就不深究。长此以往，反而会对你的技术成长产生负面影响。
唐小引：你自己是什么时候开始接触编程的？
范文栋：我敲代码应该是在读本科的时候，刚开始学的是C语言，太难了。
唐小引：那你读本科到现在有几年了？
范文栋：差不多十年左右了。
唐小引：哪怕96年的开发者，到现在也有十年编程经验了啊？
范文栋：不过本科的时候，开发强度很低，只是为了完成学业。而且那时候学的语言也比较古早，现在也没怎么用到。后来学Python，才开始用得比较多。
唐小引：那现在OWL的代码，有哪些是AICoding来的？
范文栋：CAMEL做得比较早，那时候AICoding还没那么兴起，很多代码都是手敲的。但是随着项目的发展，我们陆续加入了一些AI辅助功能后，我个人大约有超过80%的代码是通过AI生成的。不过生成之后，我会花大量时间进行代码审查，因为AI生成的代码，质量需要你自己去把控，而我修改的量大概在20%左右。
唐小引：你现在日常已经很习惯和AICoding工具一起结对编程了吗？
范文栋：对，我现在非常习惯这种方式。如果现在去掉AICoding工具，让我自己手写，我可能会有点手足无措。
唐小引：但即便如此，你还是会把AI生成的代码详细地去看，并进行代码审查，对吧？
范文栋：是的。因为AICoding可以做好局部某个点的代码生成，但如果面对的是结构复杂、层级较多的系统代码，AI往往难以理解上下文的完整性，那它给出的可能只是一个局部最优解，而不是全局最优解。
唐小引：听了文栋的经验分享，我发现即便是96年的开发者，也在不断探索与实践的过程中积累了丰富的经验，都值得我们借鉴与学习。最后，感谢文栋带来的精彩分享！
范文栋：好，谢谢大家。（投稿或寻求报道：zhanghy@csdn. net）
···
2025全球产品经理大会
8月15–16日·北京威斯汀酒店
互联网大厂&AI创业公司产品人齐聚
12大专题，趋势洞察×实战拆解
扫码领取大会PPT，抢占AI产品新红利
