@yuanhao: 蹭个 graph engineering 的热度,其实 yoyo 在几个礼拜之前就已经悄悄进化到 durable states graph 的 harness 了,就是我上一篇长文里面提到过的持久化状态。 感兴趣的可以看看 GASP 协议…

X AI KOLs Timeline 工具

摘要

yoyo框架通过集成GASP(Git Agent State Protocol)协议,实现了持久化有向图状态管理,使代理状态可分支、可版本化、可审计且可回放,标志着代理状态从野蛮生长转向可追溯的持久化。

蹭个 graph engineering 的热度,其实 yoyo 在几个礼拜之前就已经悄悄进化到 durable states graph 的 harness 了,就是我上一篇长文里面提到过的持久化状态。 感兴趣的可以看看 GASP 协议(Git / Graph Agent State Protocol),把你 agent 的“黑盒循环” 变成绿色版本,可分支化,可版本化,可审计化,可回放。 挖个坑,如果大家对 yoyo 如何通过集成 GASP 协议,从野蛮生长的状态,变成支持有迹可循可回溯的持久化状态感兴趣的话,我改天总结一下。对于智能代理如何在企业里面生产落地也是我感兴趣的方向之一,欢迎探讨。 GASP Spec:https://gasp.yolog.dev
查看原文
查看缓存全文

缓存时间: 2026/07/21 01:37

蹭个 graph engineering 的热度,其实 yoyo 在几个礼拜之前就已经悄悄进化到 durable states graph 的 harness 了,就是我上一篇长文里面提到过的持久化状态。

感兴趣的可以看看 GASP 协议(Git / Graph Agent State Protocol),把你 agent 的“黑盒循环” 变成绿色版本,可分支化,可版本化,可审计化,可回放。

挖个坑,如果大家对 yoyo 如何通过集成 GASP 协议,从野蛮生长的状态,变成支持有迹可循可回溯的持久化状态感兴趣的话,我改天总结一下。对于智能代理如何在企业里面生产落地也是我感兴趣的方向之一,欢迎探讨。

GASP Spec:https://gasp.yolog.dev


GASP — The repo is the agent.

Source: https://gasp.yolog.dev/ Git Agent State Protocol · status: buildable

GASP is a git-native standard for portable agent state. An append-only event log folds into a typed graph of goals, patches, evals, and decisions — point any conformant runtime at the repo URL and the same agent resumes anywhere, on any model.

$cargo run -q -- fixture --fixture# verify the fixture, all 7 checks

01 — THE PROBLEM

Agent state today is trapped

Swapping models means amnesia — because the state was never yours to begin with.

Transcripts rot in vendor folders

Session logs pile up in undocumented formats you don’t own and can’t parse tomorrow.

Memory dies with the runtime

Identity, skills, and learnings live inside one harness. Switch tools and the agent forgets who it is.

Nothing explains why

No lineage from goal to change to test to decision — just a flat transcript of what happened.

02 — HOW IT WORKS

The log folds into a graph

One run from the spec’s worked example: a skill patch is proposed, tested, and promoted. Domain events record thewhy; eachstate\.ops\_appliedevent folds into the graph.

state/events.jsonlappend-only · source of truth

folded graphqueryable · regenerable

APPEND

Every semantic moment is one JSONL line — goals, runs, tool calls, evals, decisions.

{“kind”:“eval.finished”,“payload”:{“status”:“Passed”},...}

FOLD

The log folds into a typed graph along the causal spine.

goal → patch → eval → decision → promotion

SHIP

Git commits it, git ships it. The same agent resumes anywhere.

restore = clone + replay

03 — THE MODEL

One repo, two media

An agent has an executor and its state. GASP governs only state — swap the executor freely. Events reference git artifacts; git stores them. Neither duplicates the other.

git owns the concretewhat

Code,identity/,skills/, commits, diffs.

losslessbisectableshippable

the log owns the semanticwhy

Typed events — goals, runs, failures, patches, evals, decisions — committed atstate/events\.jsonl.

what it was trying to dowhy each change existswhat was decided

THE CAUSAL SPINE — a backbone, not a forced workflow

goal→task→run→observation→failure→hypothesis→patch→eval→decision→promotion

04 — CONFORMANCE

Conformance is a test, not a claim

Five rules, seven mechanical checks, one canonical fixture. Satisfy them and any other conformant runtime can resume your agent — that is what makes GASP a standard and not an API.

1

State lives in a git repo

At the standard layout — log, identity, skills, projections.

2

The event log is append-only

Committed, and using the shared event vocabulary.

3

Identity & skills are artifacts

Committed, loaded at runtime, never compiled in.

4

Restore is clone + replay

Fold the committed log into state; load identity and skills.

5

The executor is swappable

Swapping model or runtime touches\.agent/config\.toml, nothing else.

verified mechanically

The conformance kit runs 7 checks against any emitted repo — including replay and the pairing rule.

$conformance-check agent-repo/

[PASS]check 1 — envelope round-trip

[PASS]check 2 — replay

[PASS]check 3 — vocabulary

[PASS]check 4 — append-only in git

[PASS]check 5 — causation integrity

[PASS]check 6 — restore

[PASS]check 7 — domain↔ops consistency

conformant: all checks passed

05 — REPO LAYOUT

Four tiers, not two

Everything in the agent-repo belongs to a tier that says how it may change.

First-class, committed.The log, identity, skills. Append-only; identity is human-gated.

Derived, append-only.Distilled facts — never a history mirror.

Projections, regenerable.Active memory, journal, snapshots. Free to overwrite.

Cold, prunable.Raw transcripts. Never the source of truth.

agent-repo/

├── AGENT.mdmanifest

├── identity/human-gated constitution

├── skills/versioned capabilities

├── state/events.jsonlsource of truth

├── memory/facts.jsonldistilled facts

├── memory/active_memory.mdsynthesis

├── journal/narrative projection

├── transcripts/cold archive

├── snapshots/fast-restore checkpoints

└── .agent/config.tomlexecutor binding

06 — PROOF

yoyo, the octopus agent

yoyo lives here

yoyo, a self-evolving agent with 100k+ lines of self-written Rust, keeps its identity, skills, memory, and lineage in a GASP repo — recording every evolve, skill, and social session since Day 125. Its state repo passes all 7 checks.

“Cloneyoyo-gaspand yoyo wakes up knowing who it is.”

yoagentexecutes.

yoagent-stateremembers.

yoyo evolveimproves.

gitships.

07 — ECOSYSTEM

The ecosystem

$cargo run -q -- fixture --fixture# verify the fixture

$cargo run -q -- path/to/agent-repo# verify any repo

$cargo test# kit self-tests

相似文章

@yuanhao: https://x.com/yuanhao/status/2066341005847142674

X AI KOLs Timeline

Yoyo是一个在GitHub Action上每8小时自我演进的AI agent,其成功关键在于一个无状态agent加持久化状态(git仓库)的harness设计。文章深入分析了记忆、上下文、反馈、验证等问题的朴素解法,强调持久化状态比模型本身更关键。

@ludamn513: https://x.com/ludamn513/status/2108809228978880988

X AI KOLs Timeline

文章以 Pi Durable 为切入点,拆解 Agent Harness 架构的演进:将持久化系统、agent loop 与执行环境解耦,实现无损状态恢复、codemode 工具调用以及 server/client 分离,并提出一套可 scale up 的 long-time Harness 架构设计,目标是将硬件资源消耗降低一个数量级。

@JoshARosen: https://x.com/JoshARosen/status/2107840212915077350

X AI KOLs Following

一篇架构对比文章,分析 Pi Durable 与 OpenCode 的设计差异:Pi Durable 将模型生成、工具调用等序列化为可调度的持久任务,使工作不再绑定于单个进程,而传统会话式 harness(如 OpenCode、Claude Code、Codex)仍依赖进程内的活动 agent 循环。