2023年9月11日，我上线了泛.AI。
那时候的 泛.AI，跟今天大家所说的“智能体”还沾不上边。它只会做一件事：用户提出一个问题，系统调用一次模型接口，再把答案返回。一次请求结束，这次交流也就彻底翻篇。下一次提问，又是一段全新的对话，彼此毫无关系。
没过多久，我把它升级成了泛.AI-pro，开始保存对话内容，引入连续对话和上下文。模型终于能够知道前面讨论过什么，我也可以在上一轮回答的基础上继续追问。
现在，它又向前迈了一步：从一个负责回答问题的对话系统，转向类似Codex工作方式的执行型智能体——理解目标、进入项目、读取文件、调用工具、执行任务、检查结果，并保存可以随时恢复的工作状态。
2026年7月11日，泛.AI开始向ORIVEX迭代。
这次变化不是简单地换一个名字、换一套界面，而是我对“智能体应该是什么”这件事，做了一次重新判断。
整个演进过程，可以概括成三句话：
泛.AI：一问一答
↓
泛.AI-pro：连续对话 + 上下文
↓
ORIVEX：目标理解 + 项目状态 + 工具执行 + 结果验证
一、为什么最早要做 泛.AI
做 泛.AI 的原因其实很现实。
当时国外模型的使用成本较高，gpt-4每月费用以及付费限制，访问地域、账号和使用门槛等限制。我希望给自己做一个统一入口，用更稳定、更方便的方式调用当时最好用的模型，并且是免费。
不管是早期的泛.AI，还是现在的ORIVEX，我都没有自己训练或部署一套大模型。底层主要还是调用GPT。选择GPT的原因也很简单：在我的实际使用中，它足够好用，综合能力也更符合我的需求。
因此，模型本身并不是我开发的。我的工作主要集中在模型之外：调用入口、服务稳定性、上下文组织、成本控制、用户空间、记忆、工作流、工具执行和结果验证。
我早期长期从事爬虫和逆向，对请求协议、接口调用和系统运行链路比较熟悉。这些经验让我能够从工程层面重新组织模型的使用方式，降低不必要的调用和重复消耗，也尽可能降低使用门槛，还能让限制的模型变得免费使用。
泛.AI 最初的目标并不宏大：
> 先让AI能够被稳定、方便地使用起来。
二、第一代 泛.AI：先把AI稳定接进自己的系统
泛.AI 早期架构设计。重点是模型接口接入、并发、负载均衡、数据库。
主要解决三个问题：
1. 多个用户访问时，服务能否承受并发；
2. 单个节点出现问题后，系统能否继续工作；
3. 用户能否通过统一入口稳定调用模型。
现在回头看，这更像一套AI接口接入方案，而不是真正意义上的智能体。
它的完整流程只有一条：
用户问题 → Web网关 → 服务节点 → 模型API → 返回答案
回答结束，任务也就结束。模型不知道用户上一次问过什么，更不可能在多个步骤之间维持任务状态。
但这一步并没有白走。它完成了最基础、也最必要的工作：我学着第一次把大模型稳定接入了自己的“泛.*”工具体系。
三、泛.AI-pro：从一问一答到连续对话
第一代泛.AI上线后，我很快发现，稍微复杂一点的问题，几乎不可能依靠一次提问解决干净。
第一次回答可能只提供一个方向。用户还需要补充条件、纠正理解、继续追问细节。如果系统不能保留前面的内容，每一次提问都必须重新解释背景。
于是，我开始升级泛.AI-pro，其实早期gpt最基本的连续对话一直是存在的，但是使用限制，泛.AI 属于我自己用的最频繁的工具还没有实现。
这一阶段最大的变化不是页面，也不是换模型，而是加入了连续对话和上下文：
– 保存当前会话的历史消息；
– 把必要的前文重新发送给模型；
– 允许用户在上一次回答的基础上继续追问；
– 增加模型选择、身份校验和对话状态提示；
– 后续陆续接入不同模型。
从一问一答到连续对话，是一次真正的能力升级。
泛.AI 只能回答“这个问题是什么”；泛.AI-pro 开始能够理解“我们刚才讨论到哪里了”。
但它的核心仍然是：
用户提问 → 模型回答 → 用户继续提问 → 模型继续回答
它能够延续一段对话，却维护不了一个长期项目；能够结合前文生成更准确的回答，却不能进入真实工作环境执行任务。
四、连续对话为什么仍然不够
随着小龙虾，以及Codex、Claude Code这类执行型产品逐渐出现，我的重心越来越少使用 泛.AI-pro，但是仍然前者仍然存在限制问题，所以我重新思考迭代它。
泛.AI-pro 虽然解决了“前后两次提问无法关联”的问题，但多轮对话和跨会话工作仍然会暴露新的边界。
1. 上下文越来越长
为了让模型记住以前说过什么，最直接的做法就是把更多历史消息重新发送给模型。
这种方式短期有效，长期却会带来两个结果：Token消耗不断增加，真正重要的信息也容易被大量历史对话淹没。
2. 记住对话不等于理解项目状态
历史消息只能说明“以前说过什么”，却不一定能说明：
– 当前目标是什么；
– 哪些决定已经确认；
– 哪些方案已经放弃；
– 项目进行到了哪一步；
– 当前阻塞是什么；
– 下一步应该执行什么。
一个真正参与项目的智能体，不能只保存聊天记录，还必须维护可以恢复的项目状态。
3. 回答正确不等于任务完成
真实工作并不止于回答问题。
写代码需要运行和测试，排查故障需要读取日志，处理数据需要核对字段和口径，完成项目还需要保存结果、记录阻塞并安排下一步。
如果智能体只能给出建议，却不能调用工具、检查结果和继续推进，那么它仍然只是一个更聪明的聊天窗口。
五、为什么现成产品很好用，我还要重新做一套
这是一个绕不开的问题：Codex和Claude Code已经足够强，为什么还要再做一个类似的系统？
答案不是为了证明ORIVEX比它们更强，也不是为了做一个商业产品，甚至可以说ORIVEX完全比不过他们。
但是ORIVEX本身不是盈利项目，更接近一个长期学习和工程实践项目。它记录了我从爬虫、逆向走向数据开发，再走向智能体工程的过程，也记录了我对AI从模糊使用到逐步理解的过程。
它要解决的是我自己的几类问题：
– 降低新模型的使用门槛；
– 减少无效Token消耗；
– 降低地域和访问方式带来的限制；
– 为每个用户建立独立的记忆空间；
– 让真实项目能够中断、恢复和继续；
– 让智能体不仅回答问题，还能调用工具完成工作；
– 面向经过明确授权的逆向分析和安全研究场景，减少笼统拒绝问题。
ORIVEX并不是简单照搬Codex，也不宣称已经具备同等能力。它借鉴的是执行型智能体的工作范式：
对话式AI：我提出一个问题，它生成一个回答
执行型智能体：我给出一个目标，它进入项目持续推进，直到形成经过验证的结果
对于已获授权的协议分析、逆向研究等任务，ORIVEX会结合本地项目规则、明确的研究边界和可用工具继续工作，而不是只根据某个关键词就中止整个任务。
这并不意味着它能够改变底层模型的全部能力和限制。ORIVEX真正能做的，是把任务背景、权限边界、工作流和工具组织得更清楚，让模型在合法授权的技术场景中少一些误判，多一些实际执行。
如下图：
看完上图可能就能理解它的优势 ， 无限制的干限制的事
六、ORIVEX重新设计了什么
1. 每个用户拥有独立记忆空间
过去的身份校验，主要用于控制谁可以进入系统。ORIVEX进一步把身份和记忆空间关联起来，让不同用户的长期信息、项目记录和使用偏好相互隔离。
这意味着，智能体面对的不再是一段临时会话，而是一个具有连续性的具体使用者。
2. 分离短期上下文、长期记忆和项目状态
不再把所有历史消息都当成同一种上下文。
– 短期上下文：当前任务正在讨论的内容；
– 长期记忆：相对稳定的个人偏好、工作方式和长期背景；
– 项目状态：已经确认的决定、当前进度、阻塞和下一步；
– 历史记录：用于追溯过程，但不默认全部加载。
分开以后，智能体不需要每次都把全部历史重读一遍，只需要根据当前任务加载真正相关的信息。
3. 重新设计Markdown规则
ORIVEX对原有Markdown规则进行了重新整理和瘦身。
规则文件不再堆积所有背景和历史，而是只保留当前执行真正需要的内容：角色边界、项目状态、工具说明、工作流入口、禁止事项和验证要求。
复杂背景按需检索，具体工作流按条件加载，历史过程不默认进入每一次请求。
4. 低Token不是简单缩短提示词
我理解的“低Token”，不是让回答变短，也不是粗暴删除上下文。
真正的目标是减少无效信息：稳定信息只保存一次，项目状态持续更新，旧历史按需检索，当前任务只加载必要内容，同时把项目全部代码化运行，真正做到代码运行零 token，隔离运行文件规则。
因此，低Token和高质量并不矛盾。上下文越精准，模型越不容易被无关信息带偏。
5. 能力存在，不等于每次都要调用
ORIVEX引入了工作流，但并不会在每一次任务中把所有规则、工具和流程全部加载。
设计原则是：
> 能力已经存在，不等于当前任务必须调用；系统正在运行，也不等于每一个步骤都需要请求模型。
只有当任务满足条件时，才加载对应Markdown规则、记忆、工作流或工具。能够通过本地逻辑完成的步骤，不重复消耗模型调用。
这才是我理解的“需要才调用”。
6. 从回答驱动转向工具驱动
ORIVEX不再只是告诉“可以怎么做”，而是开始在权限允许的范围内直接执行：读取文件、修改代码、运行命令、检查日志、查询数据、生成文档，并根据执行结果继续判断。
它需要形成一个完整循环：
理解目标 → 拆解任务 → 调用工具 → 检查结果 → 修正方案 → 保存状态
没有经过验证的结果，不能被表达为已经完成；执行失败，也不能用一段看起来合理的文字掩盖过去。
7. 让项目可以中断，也可以继续
长期项目不可能永远停留在一个会话里。
ORIVEX需要在每个关键节点保存已经确认的结果、重要决定、当前阻塞和下一步。即使任务中断，之后也能从真实状态继续，而不是重新依靠一大段聊天记录恢复现场。
8. 自我迭代必须有边界
希望智能体能够从实际执行中沉淀有效方法，但“自我迭代”绝不意味着无限制地修改自己。
真正可用的迭代应该可以追溯、验证和回退：保存了什么经验，为什么保存，适用于什么场景，出现错误后如何撤回，都必须有明确边界。
七、ORIVEX和Codex、Claude Code到底有什么不同
我可以肯定，ORIVEX不会比Codex、Claude Code更好用，很多地方甚至还差得很远。
成熟产品拥有更强的工程团队、更完整的工具生态、更稳定的运行环境，也能更快适配最新模型。ORIVEX没有必要回避这个差距。
它的意义不在于取代谁，而在于提供一套我能够理解、控制和持续修改的实验系统。取决于无限制的干限制的事。
它重点探索的是：
– 如何用更少的Token维持长期协作；
– 如何让不同用户拥有真正隔离的记忆；
– 如何按需加载规则、记忆和工作流；
– 如何在不依赖特殊网络环境的情况下使用；
– 如何适配逆向、数据和工程工作方式；
– 如何把一次模型回答变成可验证、可恢复的项目结果。
如果追求开箱即用和成熟体验，Codex、Claude Code显然是最完美的。
如果想观察一个智能体如何从一问一答、连续对话，一步步走向记忆、工作流和工具执行，那么ORIVEX就是我这几年学习和实践留下的结果。
八、模型决定上限，工具决定能力如何落地
最后必须承认：很多时候，好用首先是因为模型好用，而不是外层工具创造了模型原本不存在的能力。
同一套智能体框架，更换到更强的模型后，理解、推理、代码生成和工具选择都可能发生明显变化。选择一个合适的模型，确实可以让整个工具产生质变。
但这不代表工具层没有价值。
模型决定能力上限，智能体系统决定：
– 给模型提供什么上下文；
– 什么时候调用模型；
– 给模型开放哪些工具；
– 如何保存用户记忆和项目状态；
– 如何检查执行结果；
– 失败以后如何恢复；
– 能否把一次回答沉淀成长期成果。
ORIVEX不创造GPT的推理能力。它要做的是让这份能力以更低消耗、更适合的方式，进入真实项目并完成工作。
九、过去的技术经历，最终都进入了ORIVEX
早期做爬虫和逆向时，我习惯从请求、协议、代码和运行行为中寻找真实证据，而不是只相信表面现象；做工具时，我在意的是能否减少重复操作，能否真正解决一个具体问题；做数据开发以后，我开始更加重视字段、结构、统计口径、数据质量和可追溯性。
这些经验最终全部进入了我对智能体的理解：
– 逆向经历让我重视验证，而不是猜测；
– 工具开发让我重视落地，而不是展示；
– 数据开发让我重视结构、口径和边界；
– 长期项目让我意识到，记忆和状态比一次漂亮的回答重要得多。
ORIVEX不是对过去技术方向的否定，而是把这些能力重新组合到一个系统里。
十、为什么从泛.AI走向ORIVEX
现在这个答案交给阅读到这的你。
这就是ORIVEX目前对我最大的意义。
—
**首次上线：** 2023-12-11
**重要迭代：** 2026-07-11
**当前版本：** v0.16.11
**当前状态：** 持续开发与验证中
