You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+14-16Lines changed: 14 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,9 +14,9 @@
14
14
> [!IMPORTANT]
15
15
> OpenAgentPack is in beta. Public APIs and the `agents.yaml` schema may change before `1.0`. See the [changelog](./CHANGELOG.md).
16
16
17
-
<palign="center">
18
-
<imgsrc="https://img.alicdn.com/imgextra/i3/O1CN01xWDp5P1EP90HOZx9q_!!6000000000343-2-tps-1254-1254.png"width="360"alt="OpenAgentPack: one agents.yaml for multiple managed-agent providers">
19
-
</p>
17
+

18
+
19
+
`agents.yaml → validate → plan → apply`: bring agents back into Git, review the pending changes, then update remote resources.
20
20
21
21
One `agents.yaml` defines an agent's environment, model, instructions, tools, skills, MCP servers, vaults, and credentials. Review every change in a PR, preview it with `plan`, and apply it when ready — instead of rebuilding the same agent through console clicks.
▶ [Watch the Playground demo: switch provider and run the same agent scenario](https://github.com/user-attachments/assets/bf51b8d8-f2ed-464b-bca9-0709fefcc44d)
37
+
36
38
## Why now
37
39
38
40
Agents are moving from personal tools to enterprise digital workers. But the things that make an agent valuable — its prompts, skills, knowledge files, tools, and runtime configuration — still live mainly inside cloud-provider consoles.
@@ -45,6 +47,10 @@ OpenAgentPack puts a declarative control plane between the agent and the cloud p
45
47
46
48
The goal is to make an agent an enterprise-controlled, portable, and inheritable digital asset.
47
49
50
+
<palign="center">
51
+
<imgsrc="https://img.alicdn.com/imgextra/i3/O1CN01xWDp5P1EP90HOZx9q_!!6000000000343-2-tps-1254-1254.png"width="360"alt="OpenAgentPack: one agents.yaml for multiple managed-agent providers">
52
+
</p>
53
+
48
54
### Declaration and portability: the agent as a blueprint
49
55
50
56
Borrowing Docker's declarative idea, OpenAgentPack brings everything that determines what an agent is — model, instructions, tools, skills, environment, files, and credential references — into one `agents.yaml` blueprint. The blueprint can live in Git, pass through pull-request review, reproduce an agent, and move across providers.
@@ -68,18 +74,6 @@ The mechanics are a single `agents.yaml`, a `validate → plan → apply` workfl
68
74
-**Dependency-aware** — Environment → Skill → Agent are created in topological order; a failed dependency skips its dependents instead of leaving half-built state.
69
75
-**Drift recovery** — detects when remote config has drifted from your declaration and reconciles it. The YAML is always the single source of truth.
`agents playground` launches a local WebUI, fetches the matching `@openagentpack/playground` package on demand, and opens it in your browser. Use `--provider` to target `bailian`, `qoder`, `ark`, or `claude`.
80
-
81
-
[Watch the Playground demo video](https://github.com/user-attachments/assets/bf51b8d8-f2ed-464b-bca9-0709fefcc44d)
Run `agents playground` to launch the local WebUI, and use `--provider` to target `bailian`, `qoder`, `ark`, or `claude`. You can switch providers on the same declaration, run real sessions, and observe tool calls and artifacts.
88
+
89
+
▶ [Watch the full Playground demo](https://github.com/user-attachments/assets/bf51b8d8-f2ed-464b-bca9-0709fefcc44d)
90
+
93
91
A minimal config:
94
92
95
93
```yaml
@@ -149,7 +147,7 @@ Beta testers can install `@openagentpack/cli@beta`; see the [release guide](./do
Copy file name to clipboardExpand all lines: docs/architecture/how-it-works.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,4 +63,4 @@ agents state import <address> <remote-id>
63
63
64
64
Resources (agents, environments, skills…) are **infrastructure** — long-lived, managed by `plan`/`apply`. A **session** is a **runtime** conversation started from an agent. Sessions are managed separately with `agents session` and are not part of the plan/apply lifecycle.
65
65
66
-
Deployments sit between the two: they are declared as resources but produce runs. On Claude they schedule server-side; on Bailian, Qoder, and Volcengine Ark a `deployment run` expands into a session.
66
+
Deployments sit between the two: they are declared as resources but produce runs. On Qoder and Claude they schedule server-side; on Bailian and Volcengine Ark a `deployment run` expands into a session.
Copy file name to clipboardExpand all lines: docs/concepts/agents-as-code.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ Because the declaration is a file, it gets everything a file gets: code review,
19
19
- The **agent harness** is the provider-managed layer that wraps a model into an agent: knowledge base, skills, MCP wiring, prompt/instructions, vault, deployment, multi-agent orchestration. These are the customer's portable assets.
20
20
- The **agent infra** is the interchangeable execution substrate beneath the harness — the specific provider (Bailian, Qoder, Claude, Volcengine Ark) that runs the agent.
21
21
22
-
OpenAgentPack's portability claim is that the same harness declaration can target different agent infra. Portability means the *core declaration* is portable and the per-provider **capability contract** is explicit — unsupported facets degrade gracefully (for example, an emulated `Deployment` on Bailian/Qoder/Volcengine Ark) — not that every feature is identical on every provider.
22
+
OpenAgentPack's portability claim is that the same harness declaration can target different agent infra. Portability means the *core declaration* is portable and the per-provider **capability contract** is explicit — unsupported facets degrade gracefully (for example, an emulated `Deployment` on Bailian/Volcengine Ark) — not that every feature is identical on every provider.
A `deployment run` on Qoder expands into a one-shot session at run time; scheduling and outcome rubrics are not enforced server-side — use external cron/CI for scheduled runs.
26
+
A `deployment run` on Qoder creates a native Deployment Run and associated Session. Cron schedules run server-side.
Most commands accept `--config <path>`and `--provider <name>` to target a single provider. Run `agents <command> --help` for the definitive list.
15
+
Provider-backed commands such as `plan`, `apply`, `models`, `session`, and `deployment` accept `--provider <name>` to target a single provider. `validate` is an offline whole-file check and does not accept a provider filter. Run `agents <command> --help` for the definitive option list.
16
16
17
17
## `agents init`
18
18
@@ -30,7 +30,7 @@ Launch the local web UI (fetches `@openagentpack/playground` on demand) and open
30
30
31
31
## `agents validate`
32
32
33
-
Validate the configuration file offline — checks YAML shape and field validity without making API calls.
33
+
Validate the whole configuration file offline — checks YAML shape and field validity without making API calls. This command does not accept `--provider`; use `plan --provider <name> --refresh false` when you want to inspect one provider's projected changes without contacting remote APIs.
0 commit comments