1. 从“被动执行”到“主动规划”为什么我们需要Agentic Computation最近和几个做AI应用落地的朋友聊天大家普遍有个感觉现在的AI模型无论是大语言模型还是传统的代码执行器都太“听话”了。你给它一个明确的指令比如“调用API获取天气”它能做得很好。但如果你说“我明天要去爬山帮我规划一下”它可能就懵了。它需要你把任务拆解成“查天气”、“查路线”、“准备装备清单”等一系列原子操作然后它再按顺序执行。这种模式我们称之为“被动计算”Reactive Computation或“指令式计算”。它缺乏自主性无法理解任务的“意图”更别提在复杂、动态的环境中主动规划、决策和调整了。这恰恰是“Agentic Computation”代理式计算要解决的问题。它不是一个新的学术名词而是对下一代计算范式的迫切需求。想象一下你有一个数字助手你只需要告诉它最终目标“帮我完成这个季度的市场分析报告”。一个具备Agentic能力的系统应该能自己理解这个目标的构成需要销售数据、竞品信息、用户反馈能主动去调用相应的数据接口、分析工具甚至在发现数据源异常时能尝试寻找替代方案或向你请求澄清最终整合出一份结构完整的报告草稿。整个过程它像一个拥有自主权的“代理”Agent在给定的目标和约束下主动推进任务。而“Turn: A Language for Agentic Computation”这个标题指向的正是为了解决这个问题而诞生的一种专门编程语言。它不是Python或JavaScript的又一个库而是一种从底层设计就为了描述和驱动“代理”行为的新语言。这让我想起了早期面向对象编程语言的出现是为了更好地建模现实世界中的“对象”及其交互而Turn的出现则是为了在代码中更自然、更高效地定义“智能代理”的思维、决策和行动流程。简单说Turn试图成为编写智能体“大脑”的母语。2. Turn语言的设计哲学将“意图”与“行动”编织成程序要理解Turn我们不能只把它看作另一种语法糖。它的核心设计哲学是重新思考计算单元是什么。在传统语言中计算单元是函数或对象它们接收输入经过处理产生输出整个过程是确定性的、封闭的。但在Agentic的世界里基本的计算单元是“代理”。代理具有状态、目标、知识库和一套行动能力。它的执行不再是简单的函数调用链而是一个“感知-思考-行动”的循环并且这个循环充满了不确定性比如外部API可能失败用户反馈可能模糊。因此Turn语言的设计必然围绕几个核心抽象展开这些抽象直接映射了代理式计算的本质2.1 核心抽象一代理Agent作为一等公民在Turn中定义一个代理可能像定义一个类一样自然但内涵更丰富。一个代理的声明很可能包括身份与目标明确这个代理是谁它的长期目标或当前任务是什么。这不仅仅是注释而是可被运行时系统理解和推理的元数据。能力清单这个代理“会”做什么。这些能力可能对应着调用外部工具的函数、生成文本的LLM调用甚至是发起一个子任务委托给其他代理。状态与记忆代理需要有短期的工作记忆当前对话上下文和长期的记忆存储历史经验、知识Turn需要提供原生或极其简便的方式来声明和管理这些状态。决策逻辑给定一个状态和目标代理如何选择下一个行动这可能是基于规则的也可能是基于学习的策略。Turn需要提供一种清晰的方式来表达这种决策逻辑无论是通过声明式的规则语言还是通过嵌入可训练的模型。2.2 核心抽象二结构化通信与任务编排单个代理能力有限复杂任务需要多个代理协作。这就引出了第二个关键抽象代理间的通信和任务编排。这比简单的消息队列或RPC调用要复杂因为消息可能包含的是“请求”、“承诺”、“提议”甚至“谈判”。Turn语言可能需要内置类似“通信原语”的语法或库让开发者能轻松地描述任务分解与委派一个管理代理Orchestrator如何将一个宏大目标分解成子目标并分配给具有相应能力的执行代理。对话与协商当两个代理对某个事实有分歧或需要协调资源时它们如何通过结构化的对话可能基于LLM来达成一致。这涉及到对话状态的管理和协议的定义。观察与监督一个代理如何监控另一个代理的执行进度并在其陷入困境如循环、失败时进行干预。2.3 核心抽象三对不确定性的原生处理传统编程语言假设世界是确定的11永远等于2。但代理所处的环境是不确定的LLM的生成具有随机性工具调用可能失败用户需求可能中途改变。因此Turn语言必须将“不确定性”和“部分可观察性”作为一等公民来对待。这可能体现在概率类型系统变量的类型可能不是简单的String或Integer而是ProbabilisticString表示一个可能取值的分布。意图与承诺代理对外部世界的“理解”可能是一个概率分布意图识别它对外部世界的“影响”也是一个承诺承诺执行某个行动但可能失败。语言需要能表达和处理这种“软”状态。条件执行与回退Turn的流程控制可能大量使用“尝试-捕获-重试”模式或者更高级的“如果这个行动失败则评估备选方案B或C”的声明式语法。3. Turn可能的语法面貌与实战示例推测由于没有官方的语法手册我们只能基于其设计目标进行合理推测。一个用于Agentic Computation的语言其语法很可能在声明式和命令式之间找到平衡并且高度可读接近于“领域特定语言”。让我们设想一个简单的场景一个旅行规划代理。用伪Turn代码可能这样写// 1. 定义代理类型 agent TravelPlanner { goal: “为用户规划一次满意的旅行” capabilities: [search_flights, book_hotel, recommend_activities, negotiate_budget] memory: ConversationHistory, UserPreferences // 2. 定义核心决策循环 act on user_request: “我想去海边度假预算5000元3天2晚” { // 3. 理解用户意图可能调用LLM进行细化 let refined_intent llm_refine(user_request, context: memory) // 4. 并行尝试多个子任务 parallel { task flight_search search_flights(refined_intent.dates, refined_intent.destination) task hotel_search book_hotel(refined_intent.dates, refined_intent.destination, budget: refined_intent.budget * 0.6) } on completion { // 5. 综合结果并生成建议 let proposal generate_itinerary(flight_search.result, hotel_search.result) if proposal.total_cost refined_intent.budget { return proposal } else { // 6. 预算超支启动协商流程 initiate_negotiation(with: user, about: budget, current_proposal: proposal) } } on error task_failed { // 7. 优雅的错误处理寻找替代方案 log(“任务失败:”, task_failed) retry with alternative_parameters or suggest_alternative_destination() } } } // 8. 定义工具能力绑定到外部服务 capability search_flights(dates, destination) - List[Flight] { // 这里可能是对Amadeus或Skyscanner API的封装 // Turn可能提供一种标准方式来描述工具的输入/输出和错误码 call external_api(“flight_search”, params: {dates, destination}) }从这段假想的代码中我们可以看出Turn可能具备的一些语法特征代理声明使用agent关键字内嵌目标、能力等元数据。意图触发act on可能表示代理对特定类型输入如用户请求的响应入口。不确定性处理llm_refine函数的返回值可能是一个包含多种可能性的结构化对象而不仅仅是字符串。并发与协调parallel块用于并发执行独立子任务并定义了完成和失败时的回调。结构化错误处理on error不仅能捕获异常还能根据异常类型task_failed执行特定的恢复逻辑。能力绑定capability关键字清晰地声明了代理与外部世界的交互接口。4. Turn与现有技术栈的对比与定位看到这里你可能会想我用Python的LangChain、AutoGen或者LlamaIndex配合异步编程和良好的错误处理不也能实现类似的功能吗为什么需要一门新语言这是一个非常好的问题。我们可以从几个维度来对比维度现有框架/语言 (如 Python LangChain)Turn (推测)抽象层级库和框架级。你在用通用语言Python调用专门为Agent设计的库。你需要自己管理事件循环、状态存储、错误传播。语言级。代理、能力、通信、不确定性是语言的原生概念。编译器/运行时可能直接为你处理了并发、状态持久化、故障恢复等底层细节。表达力依赖组合。通过组合各种Tool、Agent、Chain对象来构建流程。流程复杂时代码可能变得冗长且难以维护智能体的“思维过程”散落在多个回调函数中。声明式与一体化。用更简洁、专注的语法直接描述代理的行为和交互协议。“做什么”可能比“怎么做”更突出逻辑更集中。可维护性与调试挑战较大。调试一个多代理、异步、依赖LLM的系统是噩梦。日志分散执行流非确定性高。潜在优势。语言设计时可能就考虑了可观测性提供原生的执行轨迹记录、意图可视化、状态快照等功能。调试器可能能“单步执行”代理的决策思维。性能与优化受限于宿主语言。Python的GIL和异步模型可能成为高并发代理系统的瓶颈。深度优化机会。专门的运行时可以对代理的调度、通信、记忆检索进行深度优化甚至进行静态分析来预测代理行为提前加载资源。学习曲线相对平缓。对于熟悉Python的开发者学习LangChain等库是增量式的。较陡峭。需要学习一套新的编程范式和语法但长期可能带来效率的提升。核心定位差异现有的Agent框架是“在命令式语言上建造代理大厦”而Turn试图成为“代理世界的原生建筑材料”。前者灵活但底层复杂后者专注但需要适应新的生态。5. 从热词看Turn的潜在应用场景与挑战结合网络热词“agentic rag”和“agentic rl”我们可以进一步展望Turn的应用场景1. Agentic RAG场景传统的RAG检索增强生成是“检索-然后-生成”的线性管道。Agentic RAG则让代理主动控制整个过程。例如代理可以判断初始检索结果是否相关如果不相关主动改写查询词。从多个数据源并行检索并对结果进行交叉验证和综合。在生成答案时如果发现信息缺失或矛盾可以发起新一轮的检索或向用户提问。 用Turn来描述这样一个代理的决策循环会比用Python脚本组合多个库更加清晰和健壮。2. Agentic RL场景强化学习RL智能体本身就是一个典型的“代理”。但传统的RL代码如用PyTorch大量关注神经网络和梯度计算而高级决策逻辑、环境交互的复杂性往往被埋没在大量的工程代码中。Turn有可能提供一种更高层级的语言来描述RL智能体的策略Policy和探索行为而将底层的模型训练和优化交给专门的运行时或后端。这可以让研究人员更专注于智能体行为的设计而非调试分布式采样器。然而Turn也面临巨大挑战生态从零开始一门新语言意味着新的编译器、运行时、调试器、包管理器、标准库。开发者是否愿意离开Python/Javascript庞大的生态性能与控制的权衡高级抽象通常会牺牲底层的控制力。对于需要极致性能或特殊硬件的Agent应用Turn是否还能胜任如何与现有AI模型集成如何无缝、高效地调用PyTorch、TensorFlow训练的模型或者通过API使用GPT、Claude等大模型这需要设计非常优雅的FFI外部函数接口。心智模型的转变要求开发者从“编写执行流程”转变为“定义代理行为”这是一个不小的思维跳跃。6. 对开发者与行业的启示我们该如何准备无论Turn最终是否成功它所代表的“Agentic Computation”趋势是不可逆的。作为开发者和技术决策者我们现在可以做什么1. 深化对Agent范式的理解即使不用Turn也应该用现有的框架如LangChain, AutoGen, CrewAI去亲手构建一个多代理系统。理解任务分解、工具调用、会话管理、错误处理这些核心模式。这会让你在未来评估任何Agentic技术时都有扎实的实践基础。2. 关注“状态”与“不确定性”的管理这是Agentic系统与传统软件最大的不同。去学习如何设计一个健壮的状态管理机例如使用向量数据库存储记忆使用有限状态机或行为树来管理代理状态以及如何编写能够优雅处理失败和重试的代码。3. 提升系统设计能力多代理系统本质上是一个分布式系统只不过节点是“智能代理”。你需要考虑通信协议、一致性、容错、监控等问题。分布式系统的设计经验在这里会非常宝贵。4. 保持开放与批判性当像Turn这样的新语言出现时不要急于否定或追捧。去研究它的设计理念思考它解决了哪些现有技术的痛点它的抽象是否真的带来了效率的提升。可以尝试用它的小型示例或教程亲身体验其优劣。我个人认为未来几年我们可能会看到两类路径并行一是现有通用语言Python、TypeScript的Agent框架持续进化变得越来越强大和易用二是像Turn这样的专用语言开始在小范围、高要求的场景如复杂游戏AI、自动化科研、高级虚拟助手中证明其价值。对于大多数应用开发者路径一在中期内可能仍是主流。但理解Turn所倡导的思想能帮助我们在使用现有工具时写出更符合Agentic范式的、更易于维护和扩展的代码。最终衡量Turn或任何Agentic语言成功的标准不是语法是否新颖而是它是否能让开发者更自然、更高效地构建出真正智能、鲁棒、有用的自主系统。这条路很长但起点已经清晰可见。我们正在从“编写指令”的时代迈向“培育代理”的时代。而语言始终是塑造我们思维和创造力的首要工具。