AI辅助编程：Agentic 火，要跟进么？

windsurf 带来了agentic 编程后， cursor 也火速跟进了。估计很多做 AI 辅助编程的同学估计都几不可能耐想跟进了。

在 AI 辅助编程的领域，如何充分发挥大模型的能力一直是一个值得探讨的话题。最近，我与一位业内专家就 Auto-Coder.Chat 和 Agentic 编程模式的区别进行了深入讨论，收获颇丰。在此分享我们的见解，帮助大家更好地理解这两种模式的优劣。

一次性获取完整上下文 vs. 分步执行

我们的设计理念 是让大模型在一开始就获取需求的所有上下文信息，然后充分发挥其自身的能力（包括对问题进行拆解）进行代码生成和修改。随着模型能力的提升，我们的效果也会同步提升。所以我们的核心还是在于上下文的管理上。上下文管理涉及到代码和文档两部分的管理，我们分别设计了两套子系统来满足这块的需求。

相比之下，Agentic 模式 让模型按照预先设计的流程分步执行。虽然这种方法有助于控制模型的行为，但也可能限制模型的能力发挥。此外，每个步骤之间的信息传递可能会有损耗，导致后续步骤无法充分利用前面的信息。

在 Agentic 模式中，如果要避免信息损耗，需要在每个环节传递所有信息。但这会导致 上下文膨胀，同时还会引入过多的干扰信息，影响模型的性能。这解释了为什么我们的方式效果更好——因为我们提供了更完整的上下文。

然而，在特定的问题探查中，Agentic 的一些设计流程确实能带来更好的结果。

auto-coder.chat 一些反常规的设计

大佬提出，在虚拟环境中执行代码并获取报错信息是一种优化方案。但我们认为，这个思路存在问题。如果生成的代码，方向一开始的就是错误的，那么接着跟着这个运行这个错误的代码，获取的报错信息只会引导模型在错误的道路上越走越远，陷入死循环。因为他总是聚焦在如何解决错误上，而不是反思是不是有个更好的方案。如果生成的代码出错了，那么应该反思的事，这个代码生成的好么？与其修补他，为什么再尝试一次，直接生成一次完美的答案？已经生成的代码和以及对应的错误会对模型引导很大，很难再生成更好的答案，大部分答案都是模型自身导致的问题，而不是问题的问题。

auto-coder.chat 合理的做法是，并行请求与结果筛选。我们建议的更好做法是：对同一个提示（Prompt）同时发起多次请求（例如 10 次），获取多份代码，然后进行合并和代码检查（如 Python 的 lint）。根据预设的命令运行代码，最终能够完整走完流程的代胜出。

在目前的阶段，这种方法可能比 Agentic 效果更佳。原因在于，当前的大模型（如 Claude.ai）的输出具有概率性。只要提供的信息足够完整，多次尝试中总会有一次产生理想的结果（包括解决问题的方式和最后生成的代码的质量）。

大模型在AI辅助编程中到底是什么角色

在从事 AI 辅助编程的工具开发时，虽然我们不碰大模型，但我们依然对其有自己比较独到的深入的理解。否则，可能只能开发出一些跟风的功能，缺乏创新性。举例来说，一些工具（如 Cursor）快速跟进了其他产品的 Agentic 功能，但未必能取得理想的效果，尤其是难以拉开之间的差距，大家都是一个路子，很难有护城河。

结论

当然，我们并不是否定 Agentic 这条路。在某些情况下，Agentic 确实能带来一定的出乎意料的效果。但我们认为，还有更好的方法可以探索。通过让大模型一次性获取完整的上下文信息，充分发挥其潜力，加上合理的结果筛选，我们或许能在 AI 辅助编程中取得更大的突破。