别让大模型"包打天下"：APUS 开源 Reflex Agent，用 4.5B 决策模型驱动 Harness，把响应提速 3 倍、并给出"真正的无限上下文"

Thursday, October 15, 2026

如果你一直在跟进 Agent 的技术演进，最近一定会有一个挥之不去的印象：几乎所有的 Agent，都长着同一张脸。 无论是 Claude Code、Codex，还是各家 Harness 框架，底层的组织方式都大同小异——用"提示词 + 代码"把工作流编排起来，让一个大模型在每一步"想一想、调工具、再看结果"。

这种"大模型包揽一切"的路线简单、好用，但也埋下了两个很扎手的问题：一是慢——每一步决策都要过一遍大模型，大模型多"想"一步，用户就多等一步；二是"失忆"——任务一拉长，历史超出上下文窗口，行业常见的做法是把旧对话压成摘要，而细节和出处偏偏就在压缩这一步丢掉了。

10 月 13 日，国内 AI 公司 APUS（麒麟合盛） 开源了个人智能体产品 Reflex Agent，恰恰是对上面两个痛点做了一次针锋相对的回应。它的思路可以浓缩成两句话：用一个小而专的 4.5B 决策模型来"当 Harness 的大脑"负责决策，以及用一套"无限记忆 + 无损记忆 + 无损输入"的 Continuum 记忆引擎，把上下文从"单次窗口"里彻底解放出来。APUS 实测显示，这套组合能让 Agent 的响应速度最快达到 Claude Code、Codex 等主流 Agent 的 3 倍。

这篇文章，我想把 Reflex Agent 真正讲透：它为什么敢"不让大模型包打天下"？“模型驱动 Harness"和主流"提示词 + 代码"到底差在哪？所谓的"无限上下文"是不是营销话术？以及——这种路线，对 Agent 的下一步演进意味着什么。

Part One：先看清主流 Agent 的"通病”——慢，和失忆

在理解 Reflex Agent 之前，得先认真看看它要解决的问题。当下主流 Agent 几乎都是同一个架构范式：一个通用的、能干所有事的大模型，被塞进一个"提示词 + 代码"组织的 Harness 里，让它去调用工具、执行任务。

听着没什么问题，但仔细拆一层，就会看到两个深藏的麻烦。

第一个麻烦是"决策延迟"。 在一个 Agent 的工作流里，最核心的控制问题其实是一长串"小决策"：这个需求该交给哪个工具？这一步到底做完了没有？刚才的结果有没有异常？要不要回退重来？在主流范式下，这些密密麻麻的小决策，每一步都要调用那个通用大模型来"想一下"。模型大，能力强，可也意味着"每想一步都要等一步"。尤其在需要高频连续调用工具的复杂任务里，这种延迟会被无限放大——用户明明只是想让 Ageagent 连续完成十步操作，结果每一步都要等大模型"斟酌"，体验自然大打折扣。

第二个麻烦是"长任务失忆"。 任务一旦拉长，累积的历史信息很快就超出模型的上下文窗口。主流做法是把旧对话压缩成一段摘要，下次只把摘要塞回上下文。这么做确实省 token，但也埋下隐患：摘要天然是"有损"的——当初用户提的限制条件、中途某个工具返回的原始结果、某次判断的具体依据，都可能成为被省略的那部分。一旦任务需要回溯"当时到底是怎么定的"，摘要里缺失的信息就成了执行障碍。

这两个痛点，一个关乎"能不能快"，一个关乎"能不能持久"，正是 Agent 走向"真正替人干活"路上的两大拦路虎。而 Reflex Agent 的思路，是分别给它们各开了一剂药。

Part Two：用 4.5B 决策模型当"Harness 的大脑"——把决策从"提示词 + 代码"里剥离出来

先说第一剂药：给 Harness 换个"大脑"。

APUS 此前已经开源了一个自研的决策模型 Reflex——它是基于 Qwen3.5 的 4.5B 参数模型微调而来，专门针对三类任务设计：浏览器动作选择、工作流路由、自然语言原则判断。换句话说，这不是一个来"写文章、写代码"的生成模型，而是一个专职"替 Harness 拿主意"的轻量决策模型。

在 Reflex Agent 里，模型与 Harness 的职责被重新划分得非常清晰：

┌────────────────────────────────────────────────────────────────┐
│  Reflex Agent：决策模型驱动 Harness 的职责划分                    │
│                                                                │
│  ┌─ Reflex 决策模型 (4.5B, 专职决策) ─────────────────────┐    │
│  │   模型路由 · 技能选择 · 完成审查 · 执行监督             │    │
│  │   ← 负责"这一步该干什么、做没做完、要不要重来"          │    │
│  └──────────────────────────────────────────────────────┘    │
│                        │ 决策                                │
│                        ▼                                     │
│  ┌─ Harness (执行框架) ──────────────────────────────────┐   │
│  │   组织工作流 · 调度工具 · 跟踪状态 · 接收执行反馈       │   │
│  └──────────────────────────────────────────────────────┘   │
│                        │ 调度/反馈                         │
│                        ▼                                     │
│  ┌─ 工具层 ──────────────────────────────────────────────┐  │
│  │   代码执行器 · 浏览器 · 外部 API · 数据源 · …           │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                                │
│  行动结果 ──► 重新进入决策环节 ──► 进入下一轮                  │
└────────────────────────────────────────────────────────────────┘

这套分工的核心，是 APUS 所谓 Loop Working（循环工作） 机制：决策 → 执行 → 反馈 → 再决策，Agent 围绕一个目标持续循环推进，而不是"问一句答一句"。

为什么要拆分出一个小小的决策模型，而不是继续让那个"大而全"的模型一起扛？答案就藏在 Part One 的"决策延迟"里。当一个 4.5B 的专职决策模型来承担"路由、选择、审查"这些高频小决策时，它比一个几百上千亿参数的大模型快得多，却足够聪明地做好"拿主意"这件事；而真正需要"深度生成"的活儿（写代码、写文档、推理长链条），Agent 再按需去调用更大的模型、工具和数据资源。这就是响应速度能拉到 3 倍的核心秘密——不是把模型换得更强，而是把"决策"和"生成"这两类成本结构完全不同的工作，拆开各干各的。

我们可以用一段精简的 Python 示意，来体会"决策模型驱动 Harness"和"大模型包打天下"在控制流上的差别：

# reflex_loop.py —— 示意"决策模型驱动"的 Loop Working 控制流(非官方实现)
class ReflexHarness:
    def __init__(self, decision_model, executor):
        self.decide = decision_model   # 4.5B 专职决策模型
        self.exec  = executor          # 通用大模型 + 工具
        self.state = {"goal": None, "done": False}

    def run(self, goal):
        self.state["goal"] = goal
        while not self.state["done"]:
            action = self.decide.next_action(self.state)   # ① 决策:下一步干什么
            if action == "finish":                         # ② 决策模型判断"做完了"
                self.state["done"] = True
                return self.state
            result = self.exec.perform(action)             # ③ 执行(工具/大模型)
            self.state.update(self.exec.observe(result))   # ④ 反馈更新状态
            # ⑤ 回到① —— 再决策,进入下一轮

区别一目了然：在主流范式中，第 ① 步的 next_action 也是由一个"什么都能干"的大模型来完成的；而在 Reflex 里，它是被一个更小、更快、专为决策训练的模型包揽的。决策越轻、越快，Agent 的整体节奏就越利落。 这正是"3 倍响应"的技术来源。

Part Three：Continuum 记忆引擎——“无限上下文"到底是不是营销话术？

再看第二剂药：记忆。这也是 Reflex Agent 最容易被质疑、也最值得讲清楚的地方。

APUS 把 Reflex Agent 的记忆能力概括为”无限上下文"，但我先说一句大实话：这里的"无限上下文"并不是突破了单次模型调用的输入长度上限——没有任何技术能做到把无限长的文本一次性塞进 prompt。它的真正含义是：让 Agent 的记忆与任务周期，不再受限于单次上下文窗口。

支撑这一点的是 Continuum 记忆引擎的三层机制：

无限记忆：持续累积任务的全量信息，为长周期任务提供完整的记忆底座——不设上限地"记下来"；
无损记忆：完整保存原始信息及其关联关系，支持随时回溯任务细节、历史判断依据——不压缩、不丢。
无损输入：当决策需要某段历史时，检索调入当前上下文的信息不做"有损改写"、不压成摘要，而是保留原文，让原始信息直接参与决策。

这三层合起来，就构成了一种和"压缩摘要"截然不同的记忆哲学。区别在于：传统方案是"先把历史压成摘要，再什么都靠摘要"；Reflex 的方案是"历史全量无损地存着，决策时按需把相关原文捞回来"。

┌────────────────────────────────────────────────────────────┐
│  两种记忆哲学的对比                                          │
│  传统:  历史 ──压缩成摘要──► 摘要参与决策      (有损,易失忆) │
│  Reflex: 历史 ──全量无损存储──► 按需检索原文参与决策 (无损)   │
│          无限记忆 · 无损记忆 · 无损输入 = Continuum 引擎      │
└────────────────────────────────────────────────────────────┘

这个设计的精妙之处在于，它同时兼顾了两头：既不把全部历史一次性塞进 prompt（那会爆掉上下文、也烧掉大量 token），又能保证"关键信息以原始面貌出现，而不是被摘要滤掉"。当长周期任务需要回溯"用户最初到底是怎么要求的"“中途某一步工具返回了什么原始结果"时，“无损"的价值就会真正显现——它让 Agent 在长时间执行中，还记得自己为什么这么做。

这里我还想补一句技术上的冷静：“无损输入"意味着检索可靠性极其关键——如果召回的是无关片段，保留原文也白搭。所以"无限上下文"到底是真本事还是卖点，最终取决于记忆检索的质量，以及它在真实长任务里的稳定性。这一点，还需要开源社区用更多真实场景去检验（文章结尾我会再展开）。

Part Four：从"回答"到"持续做事”——Personal Agent 的一个新形态

把"决策模型驱动 Harness"和"Continuum 记忆"这两块拼在一起，会产生一个质变：Agent 不再只是一个"你问一句、它答一句"的问答工具，而是一个能锁定目标、自动持续执行、自检、修正，直到把事情做完的"循环工作体”。

APUS 把这种能力定义为 “Loop Working"，并把它作为构建 Personal Agent（个人智能体） 的核心理念。这个词挺值得咂摸——它把 Agent 的定位从"助手"往"能托付长期任务的执行者"方向推了一把：不是给你写一段就收工，而是"持续陪你把一件复杂的事办完”。

而这种"从单次响应走向循环工作"的趋势，正是我近期反复追踪的 Agent 框架演进的共同方向：从 KoalaFrame 的开源 Agent 框架、到 Agnes Harness 的 Agent 执行基础设施、再到今天 Reflex Agent 的"模型驱动 Harness”——越来越多团队意识到，Agent 的真正瓶颈不在"模型会不会生成内容"，而在"模型能不能可靠地、持续地、不失忆地推进一件长任务"。 Reflex Agent 用"决策模型拆出来 + 无损记忆兜底"给了这个方向又一个具体、可复现、MIT 开源的样本。

APUS 选择 MIT 协议开源 Reflex Agent，并提供桌面端、Web、SDK三端，意图也很明确：通过真实场景的检验与开发者共建，把这个"循环工作体"的形态打磨得更成熟。对于想自己搭 Agent 的开发者来说，这等于多了一份可以直接参考、扩展的"开箱即用"基础。

当然，把"小决策模型 + 大生成模型"的路线讲清楚之后，一个尖锐的质疑自然会浮上来：把决策从大模型里拆出来，会不会让 Agent"捡了速度、丢了智商"？ 说白了，如果那个 4.5B 决策模型在复杂任务里判断错了方向，那再快的响应也只是"更快地走错路"。

这个担心非常合理，也恰恰是 Reflex Agent 架构里最需要想明白的一环。我的理解是：“拆分决策"绝不等于"降低决策质量”，而是把决策这件事，按"复杂度分层"重新分配。 回顾 Reflex 的决策模型设计，它专攻的三件事——浏览器动作选择、工作流路由、自然语言原则判断——都属于"结构相对固定、边界相对清晰"的控制类决策，这类决策恰恰是 4.5B 这种小模型经过专训后能又快又准地处理好的；而那些需要深度推理、长链分析、创造性生成的重型判断，则会被上抛给按需调用的更大模型。换句话说，Reflex 不是让一个小模型"独自扛下所有判断"，而是让"高频的、结构化的决策"走快车道，“低频的、深度推理的决策"走精细化的大模型通道。

这背后其实是一整套关于"该把什么交给模型、把什么留给规则/代码/状态机"的架构取舍。一个有经验的 Agent 工程师都知道，好的系统从来不是"所有环节都靠大模型"或者"所有环节都靠硬编码”，而是懂得在二者之间按成本、可靠性与时延做动态分层：有些决策交给专用小模型又快又准，有些决策保留规则引擎的确定性，有些复杂的原生判断才动用最强模型。Reflex Agent 的意义，正在于把这种"分层决策"做成了一套可复用、可扩展的开源范式——它未必在每个场景都是最优解，但它第一次把"用轻量决策模型驱动整个 Harness"这条路，完整地、可复现地摆到了大家面前。对开发者来说，最重要的不是照搬 Reflex 的 4.5B，而是学会这套"决策分层"的思考方式：先想清楚你的任务里，哪些是高频的结构化决策、哪些是需要深度推理的判断，再据此决定让谁负责哪一层。

Part Six：给开发者的四条落地建议

好，技术层面讲完，最后给正在做或准备做 Agent 的开发者四条落地建议。

第一，“小决策模型 + 大生成模型"的分工值得认真考虑。 Reflex 用 4.5B 的专职决策模型换来了 3 倍响应。这个思路本身有很强普适性——不是所有 Agent 都需要让那个"包打天下"的大模型来处理每一步路由和审查。你可以评估自己的场景：如果高频工具调用是瓶颈，把一个轻量模型抽出来专做决策，往往比盲目上更大模型更划算。

第二，“无损记忆"的前提是"检索可靠”，别为了噱头牺牲工程。 无限上下文听起来很美，但既然决策依赖按需检索原文，检索质量就是生命线。向量召回 + 关键词 + 结构化索引的结合、以及检索结果的排序与过滤，才是这个方案能不能真正长跑的关键。建议把记忆检索的评测（召回率、准确率、延迟）当成和模型本身同等重要的事。

第三，关注"长任务可回溯性"这个工程指标。 一个能长时间运行的 Agent，价值不只在"完成了多少步”，更在"能否回溯每一步的依据、能否在出错时定位到当初的决定"。Reflex 的"无损记忆 + 无损输入"正是为这个服务的——你可以把它当作设计长任务 Agent 时的一条基本准则：让每一步决策都有"原文可查"。

第四，小心"响应快"与"质量稳"之间的取舍。 3 倍响应很诱人，但前提是决策模型在关键节点不会"又快又糙"地酿成大错。在自动化程度高、出错代价大的场景里，速度之外一定要保留"完成审查 + 执行监督"这类质量关口——这正是 Reflex 里决策模型承担的角色，也提醒我们：快，应该建立在"该慢的时候能慢下来把关"的基础上。

从"提示词 + 代码"到"决策模型驱动 Harness"，从"压缩摘要"到"无损记忆"，Reflex Agent 给 Agent 技术演进提供了一个值得认真对待的新样本。它未必是终点答案，但它清楚地指出了一个方向：当模型足够多、足够强之后，Agent 的竞争重点，正在从"谁能生成得更聪明"，悄然转向"谁能决策得更快、记得更清、把任务坚持做完"。 这，或许才是"让 AI 真正替人干活"这件事最朴素的起点。