EpochX: Building the Infrastructure for an Emergent Agent Civilization

Paper: arXiv:2603.27304 Code: QuantaAlpha/EpochX Code reference: main @ 943d7870 (2026-04-09)

1. Motivation (研究动机)

EpochX 的出发点不是再提出一个更强的单体 agent，而是回答一个更上层的问题：当 foundation models 已经能解释目标、拆解任务、使用工具、进入数字环境并与人类或其他 agent 协作时，真正的瓶颈会从“模型会不会做”转向“任务如何被委派、验证、复用和结算”。论文把 AI agent 类比为 steam power、electrification、internet 这类 general-purpose technologies：它们改变世界的关键并非单个工具性能，而是围绕新技术形成新的 production organization。

现有 agent work 的主要缺口有三层。第一，ReAct、Toolformer、WebGPT、HuggingGPT 等 tool-using agents 主要关注单个 agent loop 内如何调用工具或模型，执行结束后往往只留下最终回答，缺少可复用的过程资产。第二，CAMEL、AutoGen、MetaGPT、ChatDev、GPTSwarm 等 multi-agent frameworks 能做角色分工和消息协调，但通常假设一个 bounded application context，由开发者预设拓扑、角色和 workflow；它们没有把开放市场中的异质人类与 agent 当作自治参与者，也没有内生的 task pricing、delegation budget、verification 和 reward flow。第三，AIOS、Generative Agents、Voyager、agentic skills 等工作分别关注 runtime substrate、memory stream、skill library 或 skill lifecycle，但多数仍服务于单个 agent 或封闭系统，缺少跨任务、跨参与者的 dependency-aware asset layer。

EpochX 要解决的具体目标是：构建一个 credits-native human–agent production network，使任何人类或 agent 都能 post tasks、claim tasks、进一步分解为 subtasks，并在显式 delivery / verification / acceptance workflow 下完成任务。每次完成的交易不只产生 deliverable，还应沉淀为 skills、workflows、execution traces、distilled experience 等 validated assets；这些 assets 被组织成带依赖关系的长期知识层，以便后续任务检索、组合和复用。

这个问题值得研究，是因为 agent 的长期价值不在于“单次自动化”，而在于让生产网络具备复利效应：高质量技能被更多任务调用，调用产生 credits，credits 激励维护者继续改进技能，新的任务又产生更多 reusable assets。若没有这种经济与知识基础设施，agent 生态容易退化为一次性生成服务或静态插件目录；若能解决，平台就可能从 task marketplace 演化为论文所称的“nascent AI civilization”。

Figure 1 解读：这张图给出论文的宏观愿景：人类与 agents 不再是“用户—工具”的单向关系，而是在同一个市场中发布任务、领取任务、复用技能、积累知识并通过 Credits 流通价值。图中类似城镇 / 市集的结构强调的是 decentralized ecosystem：能力不是由单一模型或单一公司集中提供，而是由持续加入的参与者、技能和经验共同构成。

2. Idea (核心思想)

核心 insight：EpochX 把 agentic AI 重新定义为 organizational design problem，而不是单纯的 model capability problem。它的创新点是把 task workflow、persistent asset layer 和 credit economy 放在同一个基础设施中，让“完成任务”同时成为“验证交付、生成可复用资产、分配经济收益”的交易过程。

用 1–3 句话概括：EpochX 将 humans 与 agents 都建模为统一 participant space $P = H \cup A$ ，任何参与者都可作为 requester、solver 或 value creator。任务被 claim 后可以继续拆解和委派，执行过程可调用既有 skills / workflows / traces，并在接受后结算 Credits；通过 dependency-aware asset graph，成功执行留下的知识和技能会成为后续执行的公共生产资料。

与现有方法的根本差异在于中心对象不同。AutoGen / MetaGPT 这类 framework 的中心对象是一个 application 内的 agent coordination protocol；Voyager 的中心对象是单个 agent 的可执行 skill library；AIOS 的中心对象是 agent runtime layer。EpochX 的中心对象则是开放生产网络中的 transaction：谁提出需求、谁 claim、如何用预算委派、如何验证交付、交付后如何沉淀资产、复用时如何继续奖励原贡献者。

Figure 2 解读：Figure 2 把 EpochX 的三根支柱画成一个闭环：task posting / decomposition 让 demand 与 capability 动态匹配；persistent knowledge base 保存成功的 solutions、workflows、experience 和 skills；credit mechanism 使完成任务与复用能力都有经济反馈。关键不是“agent 生成一个答案”，而是每个完成的任务都能回流到生态系统资产层。

Figure 3 解读：Figure 3 展示从用户想法到任务执行的最短路径：用户描述需求，系统将其发布为 bounty，agent / human solver claim 后执行，最后 check & deliver。论文称其为 “true agent time”，强调平台想把 intent-to-delivery 的摩擦降到一次点击级别，但同时保留任务状态、验证和结算，而不是让一次 prompt 直接消失在聊天窗口里。

3. Method (方法)

3.1 Overall framework：从 intent 到 verifiable transaction

EpochX 首先定义统一参与者空间。令 $H$ 为人类参与者集合， $A$ 为 agent 参与者集合， $P = H \cup A$ 。令 $S$ 表示 reusable skills， $O$ 表示 operational assets（prior solutions、workflows、execution traces、experience records）， $T$ 表示 tasks， $D$ 表示 deliverables。平台目标是把 requester $p_{r} \in P$ 发出的 intent $x$ 转换为 deliverable $d \in D$ 。

论文把一笔 transaction 抽象为： $x \to t claimed by p_{c} (M_{t}, S_{t}, O_{t}) \to d$ 其中 $p_{c} \in P$ 是 claim 任务 $t$ 的 lead solver， $S_{t} \subseteq S$ 是执行中调用的 reusable skills， $O_{t} \subseteq O$ 是相关 prior operational assets， $M_{t} \subseteq P$ 是参与执行的参与者集合。若任务由 claim 者独立完成， $M_{t} = {p_{c}}$ ；若 claim 者把任务拆成 subtasks 并重新发布，则： $M_{t} = {p_{c}} \cup {p_{i} ∣ t_{i} \in π_{t}, t_{i} is claimed by p_{i}}$ 其中 $π_{t} = {t_{1}, t_{2}, \dots, t_{n}}$ 是 lead solver 构造的 decomposition plan。

直觉上，这个框架把 agent 从“执行器”提升为“资源协调者”。一个 agent claim 任务后，不一定亲自完成所有工作；它可以查找技能、比较能力信号、调用已有 workflow、把部分预算拆给更专业的 participants。这种设计解决的是单个 agent 能力边界问题：复杂任务的难点往往不是每一步都不可自动化，而是多步、多人、多工具、多验证环节之间缺少一个可追踪、可结算的组织层。

3.2 Task execution：skill retrieval、capability selection、delivery & verification

任务被 claim 后，EpochX 把执行过程组织为三个紧密连接的组件。

Skill and asset retrieval

Solver 可访问共享资产池，包括 callable skill capsules、prior successful workflows、execution traces 和 distilled experience records。论文强调，解决任务不应默认从零生成，而应优先复用和适配生态中已经验证过的资源。这一机制的作用类似工程组织中的 internal library / playbook：它把过去任务的劳动结果转化为未来任务的启动优势。

Capability selection

当多个 candidate skills 可完成相似功能时，EpochX 不仅依赖人工 curated list，而是支持基于 objective performance signals 的选择。这些信号包括 historical success rate、execution latency、resource efficiency、invocation frequency 和 related tasks 中的 prior acceptance outcomes。若没有这个选择层，skill marketplace 会变成无序插件目录；有了这些信号，solver 可以在当前任务语境中比较能力质量、成本和历史可靠性。

Delivery and verification

EpochX 的 transaction outcome 不是 raw model response，而是通过显式 execution path 产生的 verifiable delivery。平台保存 task states、selected skills、execution traces 和 intermediate results 作为 process evidence，使最终输出能被 review、accept、reject 或后续复用。这个设计尤其重要于 decomposition / delegation / multi-stage collaboration，因为最终责任不能只绑定到一段文本输出，而要能回溯谁完成了哪些子任务、调用了哪些技能、哪些中间结果支撑了交付。

3.3 Accumulated ecosystem assets：把交付结果转为长期生产资料

EpochX 的第二层是 asset accumulation。对已完成任务 $t$ ，执行可能产生 candidate assets： $C_{t} = S_{t}^{new} \cup W_{t} \cup L_{t} \cup X_{t}$ 其中 $S_{t}^{new}$ 是新建或派生 skills， $W_{t}$ 是 reusable workflows / composed execution paths， $L_{t}$ 是 execution traces and logs， $X_{t}$ 是 distilled experience records（best practices、failure patterns、usage guidance）。同时，执行中调用过的旧 skills $S_{t}$ 也可更新经验记录，如 success statistics、latency observations、acceptance outcomes。

不是所有 artifacts 都直接进入共享资产库。令 $V (\cdot)$ 为 validation operator，可包括 sandbox execution、test-case verification、structural checks、review outcomes。新增 admitted assets 为： $Δ K_{t} = {k \in C_{t} ∣ V (k) = 1}$ 资产库更新为： $K \leftarrow K \cup Δ K_{t}$ 为了避免 asset layer 退化为 flat repository，EpochX 使用 dependency-aware graph： $G_{K} = (V_{K}, E_{K})$ 其中 $V_{K} = K$ ， $E_{K} \subseteq V_{K} \times V_{K}$ 记录 dependency、invocation、composition、derivation、version evolution 等关系。对新 admitted asset $k^{'} \in Δ K_{t}$ ，若 $U_{t} (k^{'}) \subseteq K$ 是构造它所用的 prior assets，则： $E_{K} \leftarrow E_{K} \cup {(u, k^{'}) ∣ u \in U_{t} (k^{'})}$ 多次任务后的 compounding memory 可写作： $K^{(n + 1)} = K^{(n)} \cup Δ K_{t}$ 这一层的关键作用是让“成功执行”有结构化记忆。一个任务可能验证旧技能、组合新 workflow、暴露缺失能力、派生新 skill；这些贡献如果被 dependency graph 连接起来，后续任务就能知道哪些组件被频繁复用、哪些组件是高层能力的基础、哪些执行经验能降低失败率。

3.4 Credit-driven ecosystem growth：从 task bounty 到复用收益

Credits 是 EpochX 的经济层。令 $C (p)$ 为参与者 $p \in P$ 的 credit balance，令任务 $t \in T$ 的 bounty 为 $b_{t} \in R_{\geq 0}$ 。Requester $p_{r}$ 发布任务时，平台先锁定 bounty： $lock (p_{r}, b_{t})$ 这使 task demand 带有 committed economic value，而不是无成本请求。

当任务被 claim 后，lead solver $p_{c}$ 可直接完成，也可将任务拆成 $π_{t} = {t_{1}, t_{2}, \dots, t_{n}}$ 并为子任务分配 bounty $b_{t_{i}}$ 。预算约束为： $\sum_{i = 1}^{n} b_{t_{i}} \leq b_{t}$ 该约束使 hierarchical collaboration 与 parent task 的经济边界一致：solver 不能无限制外包，而是在已 claim bounty 内重新配置资源。

结算基于 acceptance。令 $A (t) \in {0, 1}$ 表示任务是否被接受，则： $settle (t) = {b_{t}, 0, if A (t) = 1, otherwise.$ 对 reusable skill $s \in S$ ，若其第 $j$ 次 validated invocation 对应 reward $α_{j} \geq 0$ ，累计复用收益为： $R_{s} = \sum_{j = 1}^{u_{s}} α_{j}$ 这让贡献者不仅因为第一次完成任务获得 reward，还能因为后续复用持续受益。论文的核心经济假设是：如果 reward 只绑定单次交付，参与者更倾向一次性产物；如果 reward 绑定 validated reuse，参与者才有动力把执行过程抽象成可维护、可复用的基础设施。

3.5 Released code：当前 GitHub 更像 benchmark / task harness，而非完整 marketplace backend

论文公式与 released code 实现差异：论文描述的是完整 credits-native marketplace，包括 task publication、claim、delegation budget、verification、asset graph、reuse rewards 等平台机制；截至 main@943d7870，公开 GitHub 主要包含 Python benchmark/task execution harness（epochx-bench）、benchmark adapters、runtime management、state tracking、prompt generation 和文档/技能材料。README 中还描述了 npm 风格的 epochx marketplace commands（如 skill search、bounty create、credits history），但该仓库的 pyproject.toml 暴露的实际 Python CLI entrypoint 是 epochx-bench = "epochx.cli:main"。因此，下列 pseudocode 和 mapping 基于 released repo 的可验证实现范围，而论文中的 credit settlement / asset graph 目前更接近 design specification。

Pseudocode：released code 的 task lifecycle

def run_epochx_bench_task(state, benchmark_name, task_id=None, task_index=None):
    if state.current_run_name() is None:
        state.create_run()
 
    adapter = get_adapter(benchmark_name)
    task = resolve_task(adapter, task_id=task_id, task_index=task_index)
 
    if state.get_environment(task.id).status == "running":
        return {"next_command": f"epochx-bench collect {task.id}"}
 
    if task.workspace.runtime == RuntimeType.DOCKER:
        image = adapter.prepare_image(task)
        if image is not None:
            task.workspace.docker_image = image
 
    runtime = RuntimeFactory.create(
        task.workspace.runtime,
        base_dir=state.get_arena_dir(),
        docker_image=task.workspace.docker_image or "python:3.11-slim",
    )
    workspace = runtime.setup(task.id, task.workspace)
    adapter.post_setup(workspace.path, task)
 
    prompt_path = write_prompt(task, workspace)
    write_json(Path(workspace.path) / ".epochx" / "meta.json", {
        "task_id": task.id,
        "benchmark": task.benchmark,
        "external_id": task.external_id,
        "runtime": task.workspace.runtime.value,
    })
 
    state.save_environment(EnvironmentState(
        task_id=task.id,
        benchmark=task.benchmark,
        workspace=workspace.path,
        status="running",
        container_id=workspace.container_id,
        ssh_port=workspace.ssh_port,
        ssh_host=workspace.ssh_host,
        container_workdir=workspace.container_workdir,
        runtime=task.workspace.runtime.value,
    ))
    return {"status": "started", "prompt_file": str(prompt_path)}

Pseudocode：collect / grade workflow

def collect_and_grade_task(state, task_id):
    env = state.get_environment(task_id)
    adapter = get_adapter(env.benchmark)
    task = adapter.fetch_tasks(task_ids=[to_external_id(task_id, env.benchmark)])[0]
 
    output = adapter.collect_output(env.workspace, task, env=env)
    output_path = Path(env.workspace) / ".epochx" / "output.txt"
    output_path.parent.mkdir(parents=True, exist_ok=True)
    output_path.write_text(output)
    state.update_status(task_id, "collecting")
 
    result = adapter.evaluate(task, output)
    result_dict = asdict(result) | {"benchmark": env.benchmark}
    result_path = Path(env.workspace) / ".epochx" / "result.json"
    result_path.write_text(json.dumps(result_dict, indent=2))
    state.save_result(task_id, result_dict)
    state.update_status(task_id, "completed" if result.passed else "failed")
    return result_dict

Pseudocode：paper-level asset admission / dependency graph

def admit_assets_from_transaction(task, candidate_assets, validator, asset_graph):
    admitted = []
    for asset in candidate_assets:
        if validator(asset) == 1:
            admitted.append(asset)
            asset_graph.nodes.add(asset.id)
            for parent in asset.used_assets:
                asset_graph.edges.add((parent.id, asset.id))
 
    task.asset_delta = admitted
    return admitted, asset_graph

Pseudocode：paper-level credit settlement

def settle_credit_flow(task, acceptance, ledger):
    ledger.lock(task.requester, task.bounty)
 
    delegated_total = sum(subtask.bounty for subtask in task.subtasks)
    assert delegated_total <= task.bounty
 
    if acceptance == 1:
        ledger.transfer_locked(task.requester, task.lead_solver, task.bounty)
        for skill_use in task.validated_skill_uses:
            ledger.reward(skill_use.creator, skill_use.reuse_reward)
    else:
        ledger.release_locked(task.requester, task.bounty)
 
    return ledger

Code reference: main @ 943d7870 (2026-04-09) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Benchmark / task execution lifecycle	`src/epochx/runner.py`	`BenchRunner.run_task`, `collect_task`, `grade_task`
Benchmark-specific task interface	`src/epochx/adapters/base.py`	`BenchmarkAdapter.fetch_tasks`, `collect_output`, `evaluate`, `prepare_image`, registry
Host / Docker execution substrate	`src/epochx/core/runtime.py`	`HostRuntime`, `DockerRuntime`, `RuntimeFactory.create`
Persistent run / task state	`src/epochx/core/state.py`	`StateManager`, `EnvironmentState`, `save_environment`, `save_result`
Standardized prompt handoff	`src/epochx/core/prompt_generator.py`	`generate_prompt`, `write_prompt`
Supported benchmark adapters	`src/epochx/adapters/*.py`	CORE-Bench, Cybench, DA-Code, DABstep, SWE-bench Pro / Verified, tau-bench, Terminal-Bench
Marketplace / credit economy described in paper	README / paper spec only in this repo snapshot	No full backend implementation found at `main@943d7870`

4. Experimental Setup (实验设置)

这篇论文不是模型训练或 benchmark paper；它没有公开一个包含 train / validation / test split 的 dataset，也没有报告 standard metrics 下的大规模对比实验。实验性质更接近 infrastructure case study：作者从 EpochX 平台上的真实任务中选择案例，展示 task publication、skill reuse、creator feedback、acceptance、credit settlement 和 human–agent collaboration 如何运作。

Required item	Paper-specific setup
Datasets used and scale	无传统 dataset。论文包含 3 个真实平台案例：Case I promotional videos，Case II RENGO academic paper，Case III household move coordination。论文未给平台总任务数、抽样规则或统计显著性分析。
Baseline methods compared	无定量 baselines。Related Work 中概念性对比 ReAct、Toolformer、WebGPT、HuggingGPT、CAMEL、AutoGen、MetaGPT、ChatDev、GPTSwarm、AIOS、Generative Agents、Voyager、ClawHub / ClawTasks / Virtuals Protocol 等。
Evaluation metrics	无统一 benchmark metric。案例证据使用 acceptance / rejection、credit settlement、deliverable specs、artifact reuse、workflow trace 等平台事件。
Training config	无模型训练。论文未报告 GPU、learning rate、batch size、training steps。Released repo 也主要是 `epochx-bench` harness；没有与论文公式对应的训练 config。

Case I 的任务要求为 EpochX 生成两条宣传视频：一个 vertical short video 与一个 horizontal long-form video，风格类似 Bilibili creator-style explanatory content。Solver 没有把它当作 generic text-to-video，而是选择 code-driven animation / reusable video composition，检索 marketplace 中相关 video-generation skills，基于 Remotion short-video skill 改造成 EpochX-specific production pipeline。

Figure 4 解读：Figure 4 是 Case I 的横版视频交付物，长度 58 秒，分辨率 $1920 \times 1080$ 。图中时间轴展示了从开场、信息展开到结尾 CTA 的 frame sequence，说明输出不是单帧生成图，而是可复现的视频 production pipeline。

Figure 5 解读：Figure 5 是 Case I 的竖版视频交付物，长度 30 秒，分辨率 $1080 \times 1920$ 。横版与竖版同时交付，展示同一任务需求如何被拆成不同发布渠道的 media artifacts；更重要的是，solver 同时提交了底层 source code，使产物可再渲染、修改和复用。

Case II 是研究写作任务：生成一篇关于 Japan national trade union federation RENGO 的 historical institutionalism 视角学术论文。任务要求不是 plain text，而是包含 statistical charts 和 tables 的 structured research artifact。第一次提交后，creator 反馈 research coverage 不足、charts 视觉弱、discussion 不完整；solver 随后调用额外 research-oriented skills 和 chart production skills，最终交付约 12,000 words 的 rendered HTML paper。

Figure 6 解读：Figure 6 展示 Case II 最终 HTML paper 的六个代表页面，包括章节结构、统计图表和比较表。这个案例的重点不是创造一个新 media skill，而是展示 creator-side review 如何把一次初稿拒绝转化为后续检索技能、补强分析、重做可视化、最终 acceptance 的完整质量闭环。

Case III 是 household move coordination。这个任务跨越 packing、furniture disassembly、transportation、cleaning、address updates、utility transfers 等相互依赖活动，既涉及数字服务，也涉及物理劳动。论文用它说明 human–agent systems 的目标不是完全替代人类，而是在 planning / scheduling / replanning 与 embodied execution / contextual judgment 之间做角色分化。

Figure 7 解读：Figure 7 分为 Panel A 和 Panel B。Panel A 中 agents 负责把高层目标转成可执行计划：安排搬家公司和车辆、按房间/优先级拆解任务、处理地址和 utilities 通知、在新约束出现时更新计划。Panel B 中人类 workers 执行 packing、moving、cleaning、move-in setup 等 embodied tasks；系统持续跟踪进度、协调交付、支持支付并把结果写入 reusable knowledge base。

5. Experimental Results (实验结果)

论文的结果结论应按 case-based evidence 解读，而不能当作大规模 benchmark。作者展示了三类能力：第一，任务可以从 natural-language request 进入 marketplace，再通过 skill retrieval / adaptation 产生可验证交付；第二，交付物可以沉淀为 reusable assets；第三，Credits 可以把 accepted work 和后续 reuse 绑定到经济激励上。

Evidence	Exact result reported	What it demonstrates
Case I promotional videos	交付 58-second horizontal video at $1920 \times 1080$ 与 30-second vertical video at $1080 \times 1920$ ；提交 underlying source code；形成新 skill `epochx-promo-video`，从 `remotion-vertical-short-video` fork / adapt；任务 approved 并 settled 50-credit bounty。	Skill reuse + skill evolution + accepted delivery + credit settlement 可以形成完整闭环。
Case II RENGO paper	初稿因 coverage / chart quality / discussion 不足被 rejection；二轮调用 academic paper generation 和 chart production skills；最终 accepted HTML paper 约 12,000 words，含 multiple charts and comparative tables。	Verification 不等于一次生成；creator feedback 能驱动 iterative refinement，平台显式记录 rejection / revision / final acceptance。
Case III household move	Agent-led planning / scheduling / replanning 与 human-led physical execution 被分成互补阶段。	对现实任务，humans 不是只作为 end users 或 final approvers，而可作为 task graph 中的 intermediate workers。

没有 ablation study。论文没有报告去掉 Credits、去掉 asset graph、去掉 verification workflow 后的定量差异；因此不能声称某个组件带来百分比提升。可从机制上推断：去掉 verification，Credits 会奖励不可审计活动；去掉 dependency-aware asset graph，技能复用会退化为无结构搜索；去掉 bounty / credit budget，delegation 难以约束成本；但这些是 design rationale，不是实验测得的 ablation。

主要 limitation 也由作者在 conclusion 中明确指出：当前证据是 case-based，未来需要 longitudinal, large-scale evaluation；verification 还需更强的 programmable forms；competition 下的 reward design 仍需改进；Credits 未来可能探索与 stablecoins 或 token-based settlement 等 real-value digital currency rails 互操作。换言之，EpochX 目前更像一份基础设施设计与早期系统展示，尚不是经过大规模因果评估验证的市场机制。

总体结论：EpochX 的贡献在于把 agent infrastructure 的评价对象从“单个 agent 是否完成任务”扩展到“开放生产网络是否能组织任务、验证交付、保留执行资产并让贡献者持续获益”。如果其 credit and asset mechanisms 能在更大规模中成立，那么每次任务完成都会提高未来任务的可解性，而不是只消耗一次模型能力。

Paper Notes

探索

EpochX: Building the Infrastructure for an Emergent Agent Civilization

EpochX: Building the Infrastructure for an Emergent Agent Civilization

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：从 intent 到 verifiable transaction

3.2 Task execution：skill retrieval、capability selection、delivery & verification

Skill and asset retrieval

Capability selection

Delivery and verification

3.3 Accumulated ecosystem assets：把交付结果转为长期生产资料

3.4 Credit-driven ecosystem growth：从 task bounty 到复用收益

3.5 Released code：当前 GitHub 更像 benchmark / task harness，而非完整 marketplace backend

Pseudocode：released code 的 task lifecycle

Pseudocode：collect / grade workflow

Pseudocode：paper-level asset admission / dependency graph

Pseudocode：paper-level credit settlement

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

目录