Code是AI的手：姚顺雨访谈与Python-Use范式的对话

（上图由ChatGPT生成）

前面在朋友圈推荐过姚顺雨的一个采访文  说实话在看到这篇文章之前，我并不知道他是谁，也没有读过该文开头提到的他那篇有名的博文《The Second Half》

但是大概看了下这篇文章后，发现有很多的共鸣的地方，于是我读了很多遍，内容有点多，所以我不得不得动用我最高阅读礼仪：

我数了一下，有个8页笔记（比较凌乱），一般我这个动作是为我写文章做会做一些记录或者提纲才会去这样做的，所以其实你们看到的我写的公众号内容，基本都是来自于我自己的思考跟理解，当然很多文章里有大量关联性引用及细节问题，可能导致我写的内容不是那么方便阅读，只是希望能遇到有缘人，引起一些共鸣！

所以在看下面的内容之前，除了需要先看看上面开头提到的采访，还可能需要看看我之前的写的相关文章：

姚顺雨这个名字挺有意思：谐音（“尧舜禹”）他的主要方向是AI Agent的方向，据他自己在采访里说：“到现在6年了”，然后大家都知道我们前面做了个一个叫AiPy的Agent，目前我大部分的关注点也在这一块，所以我前面说的共鸣主要还是在于Agent相关的部分。

大家的认知都是不一样的，尤其是在大模型领域，所以每个人可能对Agent的认知也是一样的,在姚的采访里提到的Agent实际可能跟我们现在日常谈论的Agent还存在一些差别，姚搞的Agent实际上是一个更大的概念，因为他是从我们熟悉的LLM之前就有Agent，也就是采访文里提到的“传统的Agent”，而我们大部分的认知是在LLM诞生之后的，这个阶段是“Language Agent”，在姚采访第二部分就给出了Agent的定义：

所以这个大家就可以同频理解Agent了，在这个Agent的理解里核心在于 “环境（Environment）”-->"执行（Action）" 对于“环境”这个词来说，姚在采访里提到过很多次，你可以把这个“环境”理解为“方向”，在“传统的Agent”里选择一个好的“环境”也就是“方向”对研究者来说至关重要，所以姚反复提到了“我们需要一个更好的环境”，从他的研究经历确实是这样的，在LLM（大语言模型）出来之前，这个尤为重要，在这里需要提到另外一个采访里出现比较多的一个词“泛化”，因为在LLM出来之前，都是具体的细分的领域比如AlphaGo、用来打Dota等，而这些Agent最大的问题是没办法“泛化”，也就是不太好用下围棋的AlphaGo的模型去玩Dota，所以“环境”对于姚这种选手有着至关重要的“执念”，直到LLM的出现，尤其是在GPT3.5出来后，大语言模型本身通过语言能力实现了“泛化”，通用的Agent成为可能。由此进入“Language Agent”：

又回到了“环境”，与环境的“执行（Action）”成为关键！

Environment（环境）

而姚认为Code是“某种程度上，是AI最重要的affordance（环境给予行动者的可能性）”，他认为：“Code有点像人的手”，“对于物理世界，人最重要的affordance是手——我们围绕它制造各种工具，比如锤子、笔、筷子。但对AI、对Digital Agent（数字智能体）来说，最重要的affordance可能就是code。”

而这个理念简直就是我们之前提出的AiPy使用的Code-use（Python-use）范式理念简直一模一样！而在接下来的采访里姚还提到了：

还记得我们Python use的架构了有个核心的设计“API Calling”吗？API Calling + Python Packages Calling + Python解释器 = “万物互联” + “万物编程” + “万境直通”。

只是姚还有一个比较纠结点，那就是GUI，这个也就是我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》里提到的，类似于Claude的Computer-Use范式，基于模型的“视觉理解”的那种“泛化”效果，不过目前来看后续依赖纯“视觉”的GUI操作有点乏力，后续一些厂商提出手机或者PC上的一个自动化操作GUI的多少有点Agent 1.0（基于“剧本”工作流）结合操作。

不过在后续姚也指出：“你是想改造你的车让它适应所有路，还是改造所有路让它适应现在的车？很多时候，现实中并没有现成的API，只有GUI。但你可以人为为它构造一个API。” 这个其实跟我们提出的 API Calling + Python Packages Calling 的思路高度一致了，当你的能力覆盖不到的时候你可以通过构造API或者Package来实现，当然实际上到目前为止Python的生态已经足够强大而且还在AI时代还在不停扩展！这个也是为什么我们选择Python use来代表Code use的根本！

显然上面这些都是让我引起“共鸣”的核心关键点，但是在通读整骗的采访里，你会发现还是有一些不一样的理解？在提这个之前，我们得先提下姚在采访里提到另外一个比较多的词：“Interface”

Interface（交互方式）

其实我对这个词还是挺奇怪的，这个可能是我英文不太好，也没看过原采访视频不知道当时是用英文采访还是中文。在我看姚的采访里给最开始的印象认为他理解更加趋向于“产品”方向的，当然深度看到后面的采访可以看出他理解肯定也是“环境的交互”，所以其实我更加喜欢Action+feedback的表述，在我之前的文章里多次提到环境的交互是源于 “The Model is the Product”里的那个经典图，参考

姚在访谈里多次强调了Interface的重要性，甚至认为：“创业公司最大机会是：设计不同的interface”，就这个问题在多个章节都有提到，他举了很多例子比如Cursor、Canvas或Artifacts 这也是给我的最初的印象可能是关于“产品”交互的，但是当我看到后面聊“对于未来12到24个月，Agent领域有可能发生的事情，你有哪些预测？”的回答：

由此可以看出对于深层次的Interface的理解是还是对于环境的，在某种角度上跟我的理解还是有一定的出入，或者说角度有不一样的地方，我认为的环境交换落地在于数据（参考）：

所以当我看到上面这段姚提到“会有新的类似Cursor的产品出现”的时候，我只想说其实这种与环境直接交互的已经出现了：AiPy就是？！确实也符合“新的环境或更大环境下的Copilot”，当然我觉得姚在这个方向上的思考更趋向于基于一OpenAI公司视角下的“环境”，具体点可能更加趋向于他在采访里也是多次提到的Super App。

在姚的采访中有一句话：“如果你做一个和ChatGPT形态很不一样的东西，是会有机会的”，这句话说得比较委婉，翻译下：“如果你做的东西ChatGPT都能做的话，他们都会做！”，当在上面回答其实也提到了就是模型厂商会从一个Chatbot的范式逐步往Agentic的交互方式，最终形成一个“Super App”，一个中性化的超级“环境”，而这个形态更趋向于Manus那种云端模式，而这正是我之前里提到的Agent未来：

而我对于”环境“的理解更加趋向于“数据”，“数据决定了大模型能力的上限”，Agent时代是数据找模型，也就是上面提到的“数据驱动模型”。

根据姚的采访及实际观察到的，从最近的OpenAI的ChatGPT及Anthropic的Claude线上一系列更新来看，比如线上Chatbox模式开始推出Agent方式，包括MCP等的支持等动作，大模型厂商已经开始各自进化他们的“Super APP”，这个点其实非常有意思，之前我在朋友圈及文章里提到了Anthropic与OpenAI方向上的存在分歧的问题：Anthropic一直聚焦在编码这个角度而OpenAI展示的就是我全要。不过到现在Anthropic从Claude Code出现，觉醒了“Code use“范式在Agent方向的应用（参考），而OpenAI从Manus那看到了云端Agent的展示效果，其实姚在采访里也提到了Openai“抄袭”Manus（插一句：姚在采访里多次提到Cursor和Manus，其实这个也算一个共鸣的点，因为我每次提到大模型应用相关的就会提到Cursor和Manus，在我以往的文章里也提到一些具体的点），当然他用的是“互抄”这个词，所以Anthropic与OpenAI，甚至包括其他的国内国外的模型，最后可能大家可能又回归到了同一条路：Super App（Super Agent）。

至于PC、手机等OS上可能是另外一个表现形式，我一直认为：OS、APP、模型厂商之间必有一战，当然这种可能是一个长期入口之争！

在姚的采访中还提到了对于创业而言，这个感觉创业者在“Super App”上没有机会了，对于这个问题姚的回复还是比较有意思的：一是大厂的形态一旦固定，可能就把资源趋向于这个形态，而没有精力去关注新的交互方式，所以才有那句：“创业公司最大机会是：设计不同的interface”，当然我也觉得姚没有把这话说完整，后面可能是：你找到了不同的interface，你也就找到了给OpenAI抄袭的机会了（有点跑题了） ... 姚的原话是：

这个点其实跟我们的理念也是有共鸣的，我们的“Python-Use（Code-Use）”范式，一个核心的理念是：充分发挥大模型的能力，最终追求的是“Freedom AI（AGI）”。模型越强，那么我们的AiPy对环境交互能力越强，完成的任务能力就越强！

「环境交互决定智能边界，智能不是缺能力，而是缺环境接口。 Python-Use 的使命就是把被封印的能力解放出来。」

我们这里小节一下对于“Environment（环境）” 和 “Interface（交互方式）” 理解上，姚看到更多的是偏“产品”方向上怎么构建一个更大的更通用“环境”，并通过模型“泛化”的方式去理解并与环境进行交互，而我的理解更加趋向“数据”，我觉得这两个方向，都是非常值得思考和关注的点，可能看到不一样的点。

在“产品”角度的视角，我最近看到一个比较有意思的观点：“Chat式的AI交互是一种束缚”，然后我最近也看到一些创业项目，确实有那么点意思，不再局限于Chatbox的交互方式，而我之前的观点在于在LLM时代所有的产品都值得被重塑，看来这个重塑还得包括LLM本身相关的产品。

这种觉得这种观点倒是不是最重要的，因为说出这个观点的人的具体的理解可能跟我的或者看官你的可能都不一样，我觉得最大的问题在于：我们在做LLM相关产品时，不会去思考或者纠结Chatbox是不是不是最合适的交互方式？ 这种意识的觉醒才是最重要的！

所以我非常认同姚说的：“我们的想象力仍被以往的交互方式所限制，还有许多尚未诞生的交互方式。这些新的交互方式，会改变我们的世界”，而且我认为AiPy背后的Python-Use范式或者说Code-Use范式就属于这类范畴！

从姚提出的“Super APP是一把双刃剑”我认为这可能是他关于上“交互方式限制”的反思：OpenAI或者他是否也被“Super APP”所限制？！因为我在姚关于Agent Infra（智能体基础设施）问题上的纠结：

 其实我觉得某种角度上看，Python-use = Agent Infra 的“捷径”，可能是最优落地路径。

Context（上下文）或 Memory（记忆）

在姚的采访里有大量的内容是涉及Context（上下文）+ Memory（记忆），印象深刻的是他用人来说明环境与Context的关系：“只有人有这样的能力：进入一个环境，获得这个环境里的Context。”

当你人接触到一个环境时，产生的所有“交互”数据就是上Context，而要对这些内容的处理就是 Memory，当然这个处理会相对比较复杂，比如存储，再次提炼学习等，而上面我们提到的“Environment（环境）” 和 “Interface（交互方式）”最终可能落地到就是这个Context（上下文）或 Memory（记忆）的处理上，结构有点类似：

LLM <--> 记忆层(上下文) <--> 环境

在不同的环境形成不同的记忆层，那么对环境交互“泛化”上的处理可能在于对这些数据再处理，比如通过在某个环境的交互中形成的“长记忆”。

当然我也一直认为Memory与Context本身是一起的，里， 我把上下文部分设定为Action对应的“Feedback” + “Memory”了，在我们当时的设计里这部分的设计算是第二期工程，因为我们优先是要把这个范式落地了，而我们现在AiPy的一个核心开发点也聚焦在Context（上下文）+ Memory（记忆）这一块，这个问题是所有做Agent必然会面临的问题。要不然大神Andrej Karpathy在带火“Vibe Coding”后再一次带火了“Context Engineering”

在我的理解里上下文目前主要是两个问题：一是上下文爆炸的问题，二是注意力的问题。而这些都是非常让人头疼的问题，目前解决上下文问题主要是两个方向：

1、模型能力提升

在这里目前有出现了两个方向：一是：大力奇迹 支持大的上下文，可以看看下图：

这个主要依赖算力的支持，当然也有注意力方面的问题。

另外一个就是前几天发布的DeepSeek 3.2的一个新方向：DeepSeek Sparse Attention (DSA) ，大大降低了上下文处理的成本，所以前面我还在想这个DSA会不会是上下文方向上新的DeepSeek时刻！

在这个方向上我们只能等待模型的进化，当然这个也符合我们模型更强AiPy更强的理念...

2、就是工程化实现

这个也就是上面提到的“Context Engineering”有点差不多，可能具体考虑东西可能有差别，这个主要是在对应的Agent相关产品开发上，目前我个人觉做的比较好的还是那几个IDE产品，一个是Cursor，因为可能是很早就使用的缘故我对当时用的@codebase功能留下了深刻的印象，当时觉得RAG可能是一个处理上下文的方向，当然这个功能被Windsurf提到的grep Agent方式所替代，然后一个就是Claude Code里的提供的上下文压缩、管理等功能，Claude Code的Subagent丝滑处理印象也非常深刻，但是他们这两个都是IDE方向的，对于代码开发的场景相对比较固定，而对于Working来说就不太好说了，这个方向也是目前我们AiPy核心开发关注的一个方向。

我们回归到姚的访谈中，还提到了另外一个词：“数据飞轮”，这个是在提到“Cursor这样的公司壁垒”问题时提到的，这个核心的部分其实也就是上面提到Context（上下文）或 Memory（记忆）等数据再训练的问题，这个问题实际上我们也考虑过，其中有一个问题：“如果你是Cursor的CEO，你会去做Pre-Training的事情吗？”，当然在姚认为：“大多数公司还没有形成数据飞轮”，这个是跟产品用户基数是息息相关的！

而对于OpenAI这种大厂确实如姚所说：“现在对于ChatGPT比较重要的是Memory（记忆）”，如果你长期使用ChatGPT的话，可能非常有体会，ChatGPT会把所有用户提交的上下文记录都形成记忆，我觉得未来他们可能想做的更多，比如通过Agent/API等获取到“环境”相关的个体数据，而做精准的个人超级管理，最新发布的ChatGPT Pulse就有这种味道？！

注：上面提示词里我没有写Subject，而ChatGPT根据记忆关联到了AiPy的logo设计上了

Cost 和 Value

这个其实就是我常说的“性价比”问题，在姚的访谈里这个主要是谈到一个创业者提的问题，这个参与者觉得算力是瓶颈，而且觉得Agent的Token用量非常可怕，用户越多多成本可能越高，说实话我看到这个问题的第一反应是这个提问的哥们真是的是一个Agent的创业者吗？如果真是可能是被Manus早期平均一个任务需要2美刀，的使用方式吧，这个主要原因多半是Claude模型贵的，那个时候大家需要追求效果所以清一色的使用Claude这种顶级模型，花销确实挺贵的，另外一个方面就是多工具调用的当时一个任务评估10几分钟中间出现大量的内容数据，但是实际上在我们AiPy出来后，成本要比Manus这种少了很多，而且我们现在主推国内模型，当时AiPy诞生的时候使用DeepSeek的是非常便宜的（我10块钱的DeepSeek官方充值，测试高强度使用AiPy用了一周），效果上当时相比使用cluade3.7等模型，单次效果可能是有一些差距，但是好歹DeepSeek便宜通过AiPy的自动反馈并修复的机制多跑几次也没啥大问题，而且到现在国产模型已经大幅度把价格打下来了，而且性能也逐步提高，DeepSeek、豆包、智谱等已经把这个性价比提高了不少！所以完全不用担心这个问题。

而姚觉得在纠结Cost之前应该先考虑Value，找到一个有价值的场景是最重要的，至于Cost总有办法解决，其实这个在国外这种创业环境确实是不用考虑的，因为如果你的效果好有大把的投资机会，而在国内就不一定了～～

当然对于这个“性价比”的问题，其实我更加在意的本地部署的模型的“性价比”，从DeepSeek到智谱4.5（现在4.6已经发布了，也会继续开源，到本文为止应该还没正式开源）的开源，开源的模型效果越来越多好，对硬件的要求也越来越低，也就是性价比大幅度提升，在我们AiPy本地一体机的测试中，GLM 4.5量化版本地部署环境中，AiPy任务一次成功率达到了80%，这完全可满足大部分的企业应用场景。（有兴趣的可以联系我们，访问https://d.aipyaipy.com/d/13 加群联系群主即可）

可靠性 与 创造性

当主持人与姚聊到“什么样的任务适合Agent做”，姚觉得任务分“一类任务更注重reliability（可靠性）”，“另一类任务更注重creativity（创造力）”，另外“还有一种划分方式是：看任务的深度和广度”，我当时看到这个的时候我觉得这问题是我们之前纠结很久的一个问题，就是我们AiPy稳定性，可重复使用的问题，这个问题我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》里关于“Python-Use范式 ‘劣势’“里有提到，当然我们也有一些解决方案，除了之前提到的这些外，我们甚至发明了一个“Python Function Calling（PFC）”的机制，当然这个在我的理解里还是所有“Python Packages Calling”的范畴，传统的Function Calling是基于OpenAI的格式，使用JSON的方式去调用，而基于Python-Use下的仍然是依靠大模型直接去调用实现部署注册好的Function。具体放在插件部分调用了（注意这个部分目前CUI是不支持的），具体工具的实现代码，你可以在/plugins/目录下找到，你也可以自己注册开发对应的工具。

姚采访的内容实在是很多，涉及的点也非常多，还有很多的细节点也有很多共鸣的地方，只是有的点不在今天讨论的范畴，比如我还看到了安全方向的共鸣：

与其纠结恶的部分，不如先想想怎么发挥善的价值！

最后

当然还有很多关于训练的创业相关的一些话题，我这里就不太好惨和了，在最后其实我想说明的上面这些观点都是我个人的理解，可能与姚顺雨本身的想表达的不完全一致，而且从背景上来看姚更趋向于学术视角，而我可能更加偏工程落地视角。可惜我并不认识姚，如果有机会的话倒是挺期待有一些新的探讨！

ChatGPT对本文的评论：“姚顺雨的Agent定义提供了一个学术与系统视角，而Python-Use范式则给出了一个工程与落地视角。两者在‘Code是AI的手’这个共识点上握手，但走向的路径可能不同：一个是从环境出发构造产品，一个是从数据出发打通交互。最终，它们都指向一个问题：我们如何让AI真正伸出一只手，去触摸并改造这个数字世界。”