1. 从“做什么”到“如何做”：AI Agent开发范式的十字路口

最近在社区里，关于如何构建一个“好用”的AI Agent，讨论得越来越热。大家不再满足于简单地调用一个API，让大模型生成一段文本，而是希望它能像一个真正的“智能体”一样，理解复杂指令、使用工具、规划步骤，最终完成一个多步骤的任务。正是在这种背景下，几个名字开始频繁出现：Trellis、OpenSpec，还有那个听起来有点神秘的AGE。如果你也关注这个领域，可能会有点困惑：它们看起来都像是用来开发AI Agent的框架或工具，但社区里的讨论似乎又暗示着它们之间存在着某种“根本分歧”。这种分歧，远不止是选择哪个开源项目那么简单，它触及了AI Agent开发最核心的哲学问题：我们到底是在“组装工具”，还是在“设计大脑”？

简单来说，这场争论的核心可以概括为“任务级工具”与“轨迹级方法论”的对立。这听起来有点抽象，让我用一个生活中的例子来解释。假设你想组装一台电脑。“任务级”的做法，就像给你一个清单：一块主板、一个CPU、一根内存条、一个电源。你按照清单，一件一件地买回来，然后按照说明书（或者你的经验）把它们插在一起。Trellis和OpenSpec就更偏向这种思路，它们提供了丰富的、现成的“零件”（Skill/工具）和清晰的“组装接口”（Spec），让你能快速搭建出一个能完成特定任务（如下单购物、分析数据）的Agent。

而“轨迹级方法论”则不同。它关心的不是“零件清单”，而是“组装逻辑”本身。继续用电脑的例子，它不会先给你零件，而是先问你：你想用这台电脑做什么？是玩游戏、做视频剪辑，还是跑科学计算？然后，它会根据你的最终目标，反向推导出需要什么样的零件组合，甚至在不同的组装步骤中动态调整策略。AGE（Agent Graph Engine）所代表的就是这种思路。它不预先定义Agent具体由哪些固定工具构成，而是提供一个底层引擎，专注于管理和优化Agent在执行任务过程中产生的“思考轨迹”（Reasoning Trajectory），让Agent自己学会在复杂环境中规划和使用工具。

所以，当你看到“Trellis vs OpenSpec vs AGE”时，本质上是在选择一条AI Agent的开发路径：是追求快速、确定性地实现已知功能，还是拥抱不确定性，去构建一个能自主学习和演进的智能体？接下来的内容，我会结合最新的技术动态和社区实践，深入拆解这三者的设计哲学、核心差异以及它们各自最适合的应用场景。无论你是想快速上手实现一个实用Agent的工程师，还是对Agent认知架构充满好奇的研究者，这篇文章都会帮你理清思路。

2. Trellis与OpenSpec：以“任务”为中心的模块化拼装哲学

当我们谈论快速构建一个能干活儿的AI Agent时，Trellis和OpenSpec是目前最受实践者欢迎的两套方案。它们虽然具体实现不同，但共享着同一种底层逻辑：将复杂的智能行为，分解为一个个可复用、可组合的标准化“技能”或“工具”。

2.1 Trellis：基于“技能”的工作流编排器

Trellis的核心概念是“Skill”。你可以把一个Skill理解为一个封装好的、具有特定功能的微服务。例如，一个“搜索网络”Skill、一个“读写数据库”Skill，或者一个“调用某内部API”的Skill。Trellis框架本身，则是一个强大的工作流（Workflow）编排引擎。

它的工作模式非常直观：

1. 技能定义：开发者（或社区）预先开发好各种Skills。每个Skill都有明确的输入、输出格式和功能描述。
2. 工作流设计：当有一个新任务时，你不需要从头写代码，而是在Trellis的可视化编辑器或配置文件中，像搭积木一样，将这些Skills拖拽连接起来，形成一个执行流程图。
3. LLM作为“胶水”：大语言模型在这里扮演关键角色。它并不直接执行任务，而是作为一个“路由决策者”。当用户输入一个自然语言指令时，LLM会分析这个指令，将其与可用的Skills进行匹配，然后决定调用哪一个或哪一系列Skills，并生成调用这些Skills所需的精确参数。

为什么Trellis会火？因为它极大地降低了AI Agent的开发门槛和提高了开发效率。对于企业来说，很多业务逻辑（如查询订单、生成报告）本身就是固定的流程。Trellis允许团队将已有的API或脚本快速封装成Skill，然后通过自然语言界面暴露给用户或其它系统。它的确定性很强，因为工作流是预先定义好的，LLM只是在已知路径上做选择，减少了“胡言乱语”的风险。在GitHub上，你能找到大量围绕Trellis Skill生态的项目，大家分享自己开发的Skill，形成了一个正向循环。

注意：Trellis的“确定性强”既是优点也是限制。它擅长处理有明确步骤、边界清晰的任务。但对于那些需要临场发挥、探索性解决的全新问题，预先定义所有可能路径的工作流会变得异常复杂甚至不可能。

2.2 OpenSpec：以“规范”驱动的工具调用协议

如果说Trellis是“技能库+工作流引擎”，那么OpenSpec就更像是一份“工具使用说明书”的标准格式。它本身不是一个完整的运行时框架，而是一个规范（Specification）。

OpenSpec的核心思想是：为描述“一个工具如何被AI调用”制定一套统一、机器可读的格式。这份格式说明书（Spec）会详细定义：

• 工具的名称和功能描述。
• 工具所需的输入参数（名称、类型、描述、是否必填）。
• 工具执行后的输出格式（数据结构）。
• 可能发生的错误码及含义。

OpenSpec解决了什么问题？在它出现之前，每个AI Agent框架（比如LangChain、AutoGPT）都有自己定义和调用工具的方式。如果你开发了一个工具，想让它在不同的Agent框架里都能被使用，就需要为每个框架写一遍适配代码，非常麻烦。OpenSpec旨在成为这个领域的“USB标准接口”。开发者只需按照OpenSpec格式写一份工具描述文件，任何支持OpenSpec的Agent框架（理论上）都能直接识别并调用这个工具。

因此，当你看到“OpenSpec使用教程”时，通常是在教你如何将一个Python函数、一个REST API甚至一个命令行工具，按照OpenSpec的格式包装成一个.spec.yaml或.spec.json文件。而像speckit、superpowers这类项目，则是提供了辅助生成和验证这些Spec文件的工具集。

Trellis与OpenSpec的“合流”：在实践中，两者并不矛盾，反而可以结合。你可以用OpenSpec的格式来规范地描述Trellis中的一个Skill。这样，这个Skill不仅能在Trellis中被使用，也有可能被其他遵循OpenSpec的智能体系统所发现和调用。它们共同代表了“任务级工具”范式：通过标准化、模块化的方式，扩充AI Agent的能力边界，让LLM能可靠地使用一个不断增长的工具集。

3. AGE：聚焦“轨迹”的认知过程引擎

现在，让我们把视角转向另一边。AGE，全称Agent Graph Engine，它代表了一种截然不同的思路。如果说Trellis/OpenSpec关心的是“Agent有什么工具”，那么AGE关心的是“Agent如何使用工具”。

3.1 什么是“推理轨迹”？

要理解AGE，必须先理解“推理轨迹”这个概念。当一个AI Agent（尤其是基于LLM的Agent）处理一个复杂任务时，它内部并非一蹴而就。它会经历一个多步骤的思考过程，例如：

1. 理解问题：拆解用户指令的真实意图。
2. 制定计划：规划需要先做什么，再做什么。
3. 执行动作：调用某个工具（如计算器、搜索引擎）。
4. 观察结果：分析工具返回的结果。
5. 评估与调整：判断结果是否解决了子问题，如果没有，是计划错了还是工具用错了，然后调整策略。

这一系列内部的“思考”（Thought）、外部的“行动”（Action）以及环境的“观察”（Observation），按时间顺序连接起来，就形成了一条“推理轨迹”。它完整记录了Agent解决一个问题的认知历程。

3.2 AGE的核心：对轨迹的建模、优化与学习

AGE不是一个提供现成工具库的框架，而是一个用于构建、运行和分析这种推理轨迹的底层引擎。它将Agent的每一次推理循环（思考-行动-观察）建模为一个图结构中的节点和边，从而形成一个动态生长的“推理图”。

它的核心价值体现在：

• 轨迹可视化与调试：开发者可以清晰地看到Agent的“思考链”，在哪里陷入了循环，在哪里做出了错误决策。这对于调试复杂Agent的行为至关重要，不再是黑盒。
• 轨迹优化：AGE可以引入各种优化策略。例如，当检测到Agent在某个问题上反复尝试失败（轨迹出现循环）时，可以触发一个“反思”节点，让Agent总结教训，回溯到更早的步骤重新规划。或者，它可以并行探索多条可能的推理路径，然后选择最优的一条。
• 从轨迹中学习：成功的推理轨迹可以被保存下来，作为“示例”或“经验”，用于指导未来解决类似问题。这为Agent的持续学习和能力进化提供了可能。

一个具体的对比：假设任务是“帮我找出上个月销售额下降的原因”。

• Trellis/OpenSpec 路径：你需要预先定义一个工作流，比如：1. 调用“查询数据库”Skill获取销售数据；2. 调用“数据分析”Skill生成报表；3. 调用“总结”Skill给出原因。LLM的作用是按顺序触发这些技能。
• AGE 路径：你给Agent一个目标，并提供一组基础工具（查询、计算、搜索等）。Agent可能会自主产生这样的轨迹：思考“销售额下降可能有哪些原因？” -> 行动“搜索‘常见销售额下降原因’” -> 观察“得到竞争、产品、季节等原因列表” -> 思考“我需要数据来验证竞争原因” -> 行动“查询数据库获取市场份额数据”… 这个过程是动态生成的，不是预先写死的。

AGE的理念更接近我们对“通用智能”的想象——具备规划、工具使用、反思和从经验中学习的能力。像“Harness”这类被描述为“包裹在AI Agent核心推理逻辑之外的基础设施层”，其思想与AGE是契合的，它们为这种自主推理提供内存、知识库、工具调用等底层支持，而不干预推理逻辑本身。

4. 根本分歧：确定性组装与涌现性智能的路线之争

理解了双方的基本盘，我们就能看清这场“分歧”的本质。这不仅仅是技术选型的差异，更是两种AI Agent发展路线的哲学碰撞。

4.1 设计哲学对比

4.2 实际应用场景的选择

理解了分歧，我们该如何选择？答案取决于你要解决什么问题。

选择 Trellis/OpenSpec 当：

• 你有明确的、重复性的业务流程：例如，客服自动问答（查订单、退换货）、内部数据查询机器人、自动化周报生成等。这些流程步骤固定，只是触发条件变成了自然语言。
• 追求稳定性和快速上线：你需要一个今天搭建、明天就能稳定运行的Agent。任务级工具范式风险低，见效快。
• 需要集成大量现有系统：企业内有成百上千的API和数据库。用OpenSpec将它们快速封装成工具，用Trellis编排，是性价比极高的集成方案。
• 团队技能栈偏工程而非研究：这种模式更接近传统的软件开发，易于理解和管理。

选择 AGE 或类似轨迹引擎 当：

• 你面对的是开放域、探索性问题：例如，一个研究助手需要阅读多篇新论文并综合观点；一个战略分析Agent需要根据实时新闻和市场数据给出投资建议。这些问题没有标准答案，路径也无法预先穷举。
• 你追求Agent的“智能”和“自主性”：你希望Agent不仅能执行指令，还能主动发现问题、制定复杂计划、从失败中学习。
• 你的项目带有研究性质：你愿意为了更高的智能上限，而接受其不确定性和更复杂的调试过程。你对Agent的“思考过程”本身感兴趣，并希望优化它。
• 任务环境动态变化：例如，游戏AI、机器人控制，环境反馈实时且多变，需要Agent在线调整策略。

5. 融合与展望：混合架构与开发者学习路径

纯粹的争论没有意义，未来的趋势很可能是融合。事实上，许多前沿的框架已经开始尝试结合两种范式的优点。

5.1 混合架构的实践

一种典型的混合思路是“分层架构”：

1. 底层：一个像AGE这样的轨迹引擎，负责核心的推理、规划和学习。
2. 中层：一个丰富的工具层，这些工具严格遵循像OpenSpec这样的统一规范进行描述和注册。
3. 连接层：轨迹引擎在需要时，可以无缝、可靠地调用中层的任何工具。同时，对于一些非常成熟、固定的子任务，也可以直接调用一个由Trellis编排好的、确定性的“宏技能”（Macro-Skill）。

这样，Agent既具备了自主解决新问题的潜力，又在执行具体操作时获得了确定性和可靠性。社区中关于“LLM、Agent、RAG、Harness层级架构”的讨论，正是这种分层思想的体现。RAG（检索增强生成）负责知识获取，Harness（基础设施层）提供持久化、工具调用等支持，而Agent（核心推理）则在顶层进行协调。

5.2 给开发者的学习建议

如果你刚刚进入AI Agent领域，面对这些概念感到迷茫，我的建议是：

第一步：从“任务级”入手，建立手感。不要一开始就追求最先进的轨迹引擎。先去学习OpenSpec，尝试把你的一个Python函数包装成工具描述文件。然后使用一个支持OpenSpec的简单框架（或直接利用LangChain等成熟框架的工具调用功能），让LLM去调用它。这个过程会让你深刻理解“工具调用”这个最基本、最核心的Agent能力。接着，可以尝试Trellis，体验一下将多个工具串联成工作流的感觉。这一步能帮你建立起对Agent能力的具象认知，并快速做出可演示的原型。

第二步：深入理解“提示工程”与“思维链”。在你能熟练让Agent使用工具后，要进一步提升其智能，关键在于提升其“思考”质量。这就要深入研究提示工程（Prompt Engineering），特别是思维链（Chain-of-Thought, CoT）和思维树（Tree of Thoughts, ToT）等技术。这些技术是轨迹级方法论的“前身”和“灵魂”。通过设计好的提示词，你能引导LLM进行更复杂的推理规划，这实际上就是在手动塑造“推理轨迹”。这是通往理解AGE类引擎的必经之路。

第三步：探索轨迹引擎与高级架构。当你对工具调用和复杂推理都有了实践经验后，再去研究AGE、AutoGPT（早期探索者）或者类似强调长期记忆和反射的框架。此时，你就能看懂它们的架构设计在解决什么问题：如何管理冗长的上下文？如何让Agent从历史轨迹中学习？如何避免推理循环？这时，你的视角就从“如何使用框架”上升到了“如何设计一个更智能的Agent系统”。

AI Agent的开发，正处在一个从“功能拼接”向“认知构建”演进的关键阶段。Trellis和OpenSpec代表了工程化、标准化、可大规模复制的现在，而AGE则指向了更自主、更灵活、更智能的未来。作为开发者，理解这场“根本分歧”，不是为了选边站队，而是为了看清地图上的不同路径，从而根据你的项目目标和资源，选择最适合的起点和方向。毕竟，最好的技术永远是那个能解决你实际问题的技术。