#智能体

2周前
转译:为什么生成式 AI 编程工具和智能体对我没用 作者:Miguel Grinberg 人们总是问我,我是否使用生成式 AI 工具来编程,以及我对它们有何看法。因此,我决定将我的想法写下来,这样以后再有人问起,我就可以直接把这篇文章甩给他们,而不必每次都重复自己的观点。 从标题你大概已经猜到,这不会是一篇吹捧 AI 的博文。但它也不是一篇反对 AI 的文章,至少我不这么认为。市面上已经有太多 AI 吹和 AI 黑写的文章了,我觉得没必要再多我这一篇。虽然在这个话题上我绝非中立,但在这篇文章里,我只想从纯粹技术的角度,分享我个人使用这些工具的真实体验。 AI 并不更快 说真的,生成式 AI 工具对我没用的最主要、也是最重要的原因是:它们并没有让我写代码变得更快。就这么简单。 使用生成式 AI 编程工具来为我写代码,听起来很容易。如果是一个 AI 智能体,那就更方便了,它在我做别的事情时就能直接编辑我的文件。原则上,这一切听起来都很美好。 但问题在于,我需要为这些代码负责。我不能盲目地把它们添加到我的项目中,然后祈祷一切顺利。只有在我彻底审查并确保完全理解了 AI 生成的代码之后,我才可能将其整合进我的项目。我必须有信心在未来能够修改或扩展这段代码,否则我就不能用它。 不幸的是,审查代码实际上比大多数人想象的要困难得多。审查一段不是我写的代码,至少要花掉我与亲手写这段代码相同的时间,甚至更多。我们行业里有句名言,大意是“读代码比写代码更难”。我记得最早将此概念理论化的人是 Joel Spolsky(Stack Overflow 和 Trello 的创始人),在他的文章《有些事你永远不该做,第一部分》中提到了。 你可能会说,可以把 AI 写的代码当成一个“黑箱”。我想,你可以说服自己,只要代码能按预期工作,就可以安全使用,无需审查,这样就能提升一些生产力。但在我看来,这是极不负责任的,因为如果这段代码将来出了问题,AI 是不会承担任何责任的。无论有没有 AI,我永远是我产出的代码的第一负责人。在我看来,承担如此巨大的风险是疯狂的。 这一点在我从事的某些工作中尤为重要,因为这些工作涉及签署合同、法律义务和金钱交易。如果我是以专业人士的身份被雇佣,那我别无选择,只能做到专业。AI 工具无法帮我赚更多钱,也无法让我在更短时间内完成工作。我唯一能通过它实现这些目标的方式,就是牺牲工作质量并引入风险,而这是我绝不愿意做的。 AI 不是生产力倍增器 我听过有人说,生成式 AI 编程工具对他们来说是生产力的“倍增器”或“赋能器”。基本上,持这种观点的人声称,使用生成式 AI 后,他们能工作得更快,也能处理更复杂的问题。可惜的是,这些说法仅仅基于使用者自身的感觉,并没有确凿的数据来支持。我猜,或许有些人审查代码的效率比我高,但我对此表示怀疑。我认为真实情况是,这些人之所以能节省时间,是因为他们只对 AI 生成的代码进行抽查,或者干脆跳过了整个审查阶段——正如我上面所说,这对我来说是绝对无法接受的。 另一个我常听到的论点是,当你需要用一种不熟悉的语言或技术编写代码时,生成式 AI 会很有帮助。对我来说,这同样没什么道理。作为一名软件工程师,我最享受的部分就是学习新事物,所以“不懂”从来都不是我的障碍。你越是练习学习,学习的速度就会越快、越容易!近年来,我为了不同的项目,不得不学习了 Rust、Go、TypeScript、WASM、Java 和 C#,我绝不会把这个学习的过程委托给 AI,哪怕它能帮我节省时间。当然,它也省不了,原因还是上面那些——我要为我产出的代码负责。抱歉,我在这点上有点啰嗦。 AI 代码不同于人类代码 前几天我和一个朋友聊起这些观点,他问我,既然如此,为什么我乐于接受人们为我的开源项目所做的贡献呢?那些不也是别人写的代码吗?为什么人类写的可以,AI 生成的就不行? 真相可能会让一些人感到震惊:用户提交的开源贡献其实也并不能节省我的时间,因为我同样觉得必须对它们进行严格的审查。但是我享受与那些对我的项目感兴趣并花时间报告 bug、请求新功能或提交代码修改的用户合作。这些互动首先是新思想的源泉,它们直接帮助我把工作做得更好。这正是我热爱开源工作的地方! 我的朋友仍然不服气,他建议我可以并行启动一堆 AI 智能体,为我所有未解决的 bug 创建拉取请求(PR)。“这会改变游戏规则的!”他说。不幸的是,这只会花掉我的钱,并且可能让我变得更慢,原因已如前述。即便我们假设 AI 编程工具已经足够成熟(实际上还差得远),能够在很少或没有监督的情况下修复我项目中的问题,我仍然是那个瓶颈,因为所有这些代码在合并之前都必须经过我的审查。 AI 编程工具唾手可得,其不幸的一面是,现在一些用户也用它们来生成低质量、敷衍了事的拉取请求。我已经收到过一些这样的 PR,有趣的是,当我开始阅读那些未经真人编辑和润色的 AI 代码时,一种“恐怖谷”效应在我心中油然而生。当我遇到这类 PR 时,我会开始向提交者追问他们代码中那些奇怪的部分,因为我认为他们需要为自己想要合并的代码负责。但他们,通常很少回应。 AI 不等于实习生 许多 AI 倡导者说,你应该把你的 AI 编程工具当作一个渴望取悦你的实习生。我认为说这话的人,大概从没带过实习生! 在初期,将工作委派给实习生会导致你的生产力下降,原因和我上面列举的差不多。实习生需要大量手把手的指导,他们产出的所有代码在被接受前都需要仔细审查。 但是,实习生会学习并随着时间的推移而进步。你花在审查代码或向实习生提供反馈上的时间并没有被浪费,这是对未来的投资。实习生会吸收你分享的知识,并将其用于你之后分配给他们的新任务中,随着实习期的推进,对他们进行密切监督的需求会逐渐减少。最终,实习生常常因为成长为成功的独立贡献者而被公司聘为全职员工。 而一个 AI 工具,最多只能算是一个患有“顺行性遗忘症”的实习生,这可不是什么好实习生。对于每一项新任务,这个“AI 实习生”都会重置回原点,什么也没学会! 结论 我希望通过这篇文章,我已经清楚地阐述了我在工作中应用生成式 AI 编程工具时遇到的技术性问题。 根据我的经验,AI 编程这回事,天下没有免费的午餐。我相信那些声称 AI 让他们更快或更高效的人,是为了实现这些收益而有意识地选择放宽了他们的质量标准。要么是这样,要么他们这么说,只是因为他们自己能从向你推销 AI 中获利。
2个月前
划重点:知道 Deep Research 智能体的架构后怎么更好的使用 这里课代表帮你划一下重点: 有记忆 这意味着中间结果会被保存下来。所以每次扣子空间的任务,你不仅可以看最终的网页,还可以看一些中间结果的 Markdow 等其他文件,这些文件有时候也会包含有价值的信息 有安全过滤 这意味着你就不用想着用它做什么模型不允许做的事情,基本上是徒劳的 有最强模型 由于 Deep Research 对模型能力要求特别高,这意味着各家都会用自己最强的模型出来做这件事,比如OpenAI 刚推出 Deep Research 时,它就是用的当时最新最强的 o3 模型,所以有些对模型能力要求高的任务,也可以让 Deep Research 来做,比如我就常用 Deep Research 分析代码库、参考代码库写一个 MCP 服务之类的,效果比普通对话模型效果还好。 有工具 这意味着它有一些特别的能力,比如代码执行、浏览器、PDF 解析、网页制作等,说明你可以借助它的一些工具来做一些报告之外的事情。比如我曾借助 OpenAI Deep Research 的 PDF 解析工具的能力,来帮我把 PDF 解析成 Markdown,甚至完整的翻译成中文。 特别值得一提的是,OpenAI 和 Gemini 的 Deep Research,只能使用默认的几个工具,但是像扣子空间,它的工具接入了 MCP 扩展,也就意味着可以接入现在火爆的 MCP 生态。比如说你要出行规划,就可以加上高德地图和墨迹天气的 MCP 扩展,让出行规划既能考虑天气因素,又能考虑交通拥堵、道路施工情况。 扣子空间不仅有官方的 MCP 扩展,比如官方 MCP 刚上新了水滴信用、音乐生成,另外你还可以自定义 MCP,「扣子开发平台」商店千余插件,个人无限 DIY 工作流,均可发布至「扣子空间」,让无限海量的MCP 为你的 Deep Research 任务所用。 除了这些 Deep Research 独有的功能,还不可忽视我们在使用 对话类 AI 应用时两个重要的元素:输入和输出。 输入: Deep Research 并非只能输入文本,你还可以输入URL、图片、PDF 等其他格式的内容 输出: 不同家的 Deep Research 支持的输出也不同,比如 OpenAI 的 Deep Research 只能输出 Markdown,Gemini 能将结果到处到 Google Docs,扣子空间则可以生成可交互的网页、图表,还可以生成 PPT。在扣子空间,你要是让它处理 PDF,还能拿到提取的文本文件。 当我们知道 Deep Research 的这些“秘密”之后,就不用再局限于用它去写个调研报告,还可以用它做很多其他事。