框架正在收敛到同一个形状
过去一年半，开源智能体框架的数量增长很快，但把它们的架构摊开看，形状其实在收敛：一个协调者，一池子智能体，一份共享的任务清单，外加一个沙箱。差别更多落在细节上——谁来决定怎么拆任务、子智能体之间怎么通信、失败之后如何回滚。
Apodex 在 8 月下旬开源的 FrontierAgent，切入点是其中一个具体的争论：任务分解究竟应该是外挂的脚本逻辑，还是模型自身的一项能力。公司的立场很明确——拆不拆、拆几个、什么时候合并，应该由模型在推理时自己决定，而不是由一层固定流程替它安排。项目采用 Apache 2.0 许可，把运行时、终端界面与评测台放在同一个仓库里。
一个仓库里的四层
按公开说明，FrontierAgent 的结构被有意拆成几层。通用循环层负责调度、注册表、智能体总线与观察者机制，不依赖任何具体基准；插件与工具层提供网页、shell、文件、沙箱以及团队协作工具的实现；工作流层放 ReAct 与 Agent Team 两条管线，以及配置、提示词与观察者；对外层则是一个终端命令行与文本界面，负责审批、会话、追踪记录与容器路径；此外还有独立的基准目录，装着公开评测台以及项目自带的两套基准。
这种分层的意义在于：框架层不依赖基准层。也就是说，你可以只用它的运行时来跑自己的任务，而不必被它的评测设计绑住。对一个想自己动手验证的团队来说，这一点比较实用。
两条工作流
项目自带两条工作流。一条是有状态的 ReAct 单智能体，走的是经典的「想一步、做一步、看结果」循环。另一条是 Agent Team 模式：一个协调者维护任务板，把子任务派发给并行的子智能体，收集它们返回的结构化报告，再综合出答案。
更关键的是，同一套引擎也用来跑公司自己公布的基准。这意味着外部团队可以在自己的机器上复现「ReAct 对比 Agent Team」的差异，而不必只听结论。对一份厂商自报的成绩来说，能提供复现路径，比多报几个分数更有价值。
几个可以核对的事实
按 9 月 12 日核实的信息：项目在 GitHub 上有约 2664 个星标、179 个复刻、13 个未关闭议题；仓库创建于 2026 年 8 月 22 日，最近一次推送在 9 月 12 日。技术栈是 Python 3.12 加 uv，可以对接任何兼容 OpenAI 接口的端点，而不限于公司自家的模型。配套的 Apodex-1.1-mini 是一个 350 亿参数的混合专家模型，基于 Qwen3.5-35B-A3B 构建，支持 26.2 万令牌上下文，在模型平台上有超过 9400 次下载。
任务执行被限定在一个固定结构的沙箱里：输入目录只读，工作目录可写，产物输出到指定目录；在 Linux 上使用 bubblewrap 或容器隔离，授权策略采用失败即拒绝的方式。项目还提供审批门、记录每一步动作的 JSONL 追踪、用一条命令回滚某个会话，以及断点续跑。
评测部分自带 14 个基准，涵盖深度检索、综合推理、专业工作流与办公问答等方向。
那组被引用的数字
公司给出的主张是：任务分解应当是模型的训练能力，而不是包在模型外面的脚本。对应的数字是——在同一个模型上，Agent Team 模式比纯 ReAct 高出 4.1 到 9.3 分；350 亿参数的 Mini 在 Agent Team 模式下，在某专业工作流基准上达到 27.7 分，而一个参数量约一万亿的对照模型为 27.9 分。
这组数字如果成立，含义不小：一个量级小得多的模型，靠任务分解与并行子智能体，逼近了一个大得多的模型的成绩。但它需要加上两条限定。其一，这些是厂商基准，其中两套（面向金融与研究场景的基准）是公司自己构建的。其二，最能说明问题的问题不是「它能不能拿高分」，而是「换一个模型、用同一套测试台，Agent Team 模式是否同样带来提升」。这一点，项目恰好提供了复现条件。
也必须说的另一面
项目还很年轻——按创建时间算，发布才三周左右。而它的议题列表里，已经出现了与安全相关的缺陷：一处涉及 shell 允许列表，另一处涉及命令超时时的进程泄漏。这两类问题在智能体框架里都属于需要认真对待的类型，前者关系到隔离是否真的生效，后者关系到资源是否会被拖垮。
对打算试用的团队来说，这意味着两件事：一是不要把当前版本直接放进对安全性敏感的环境；二是关注议题的修复进度，而不是只看星标数。星标增长快，说明关注度高，不说明代码已经稳。
中立思辨
需要辩证看待几件事。其一，把任务分解交给模型，在灵活度上是加分项，在可预测性上是减分项。固定流程虽然笨，但每次运行走的路径一致，出问题好归因。让模型自己决定拆不拆，意味着同一任务的资源消耗与耗时可能波动较大。哪种更好，取决于场景是重效率还是重可审计。
其二，厂商基准需要独立复现。项目提供了复现路径，这是加分项，但复现结果是否支持同样的结论，仍要看第三方。在此之前，那组分数应被当作方向性提示。
其三，「协调者加并行子智能体」这套结构本身不是新发明，行业里已有多个类似项目。FrontierAgent 的差异更多在于把运行时与评测台打包在一起，以及它对任务分解归属的立场。把它当成一条可选路径，而不是范式突破，更接近实际。
其四，一个三周大的项目，接口与目录结构都可能快速变化。现在投入集成的团队，要为后续的破坏性变更留出余量。
其五，各基准的具体得分明细、完整任务集与长期维护计划，公开材料未充分展开。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给工程团队的四条做法
把这次发布背后的判断拆出来，有四条可以直接用。
先在自己的任务上做对照实验。同一个模型，分别跑单智能体与团队模式，比较成功率、耗时与成本。厂商的分数只能做参考，你自己的曲线才决定要不要用。
把沙箱边界当成验收项。确认输入是否只读、工作目录是否隔离、命令执行是否可越权、超时之后进程是否被回收。这几条比模型选择更影响安全。
为并行留出成本预算。并行子智能体会同时消耗算力与接口配额。在扩大并发之前，先测出单任务的成本，再乘以并发数，避免账单失控。
跟踪议题，而不是只看星标。一个年轻项目的成熟度，体现在缺陷修复的速度与质量上。把它加进观察清单，等隔离相关的问题关掉之后再考虑上生产。