@penguinharness/agent-development 0.2.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +201 -0
- package/icon.svg +6 -0
- package/package.json +21 -0
- package/plugin.json +8 -0
- package/skills/penguin-config/SKILL.md +71 -0
- package/skills/penguin-orchestration/SKILL.md +161 -0
- package/skills/penguin-sdk/SKILL.md +359 -0
- package/skills/unified-llm-api/SKILL.md +196 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright [yyyy] [name of copyright owner]
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/icon.svg
ADDED
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round" stroke-linejoin="round">
|
|
2
|
+
<path d="m12 3 8 4.5v9L12 21l-8-4.5v-9z" />
|
|
3
|
+
<path d="m4 7.5 8 4.5 8-4.5" />
|
|
4
|
+
<path d="M12 12v9" />
|
|
5
|
+
<path d="m8 5.25 8 4.5" />
|
|
6
|
+
</svg>
|
package/package.json
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@penguinharness/agent-development",
|
|
3
|
+
"version": "0.2.9",
|
|
4
|
+
"description": "Agent development on PenguinHarness: build on the SDK, call any model through one unified LLM API, manage models and secrets, and orchestrate agents, sessions, costs and schedules.",
|
|
5
|
+
"license": "Apache-2.0",
|
|
6
|
+
"repository": {
|
|
7
|
+
"type": "git",
|
|
8
|
+
"url": "git+https://github.com/Prism-Shadow/penguin-harness.git",
|
|
9
|
+
"directory": "plugins/agent-development"
|
|
10
|
+
},
|
|
11
|
+
"files": [
|
|
12
|
+
"plugin.json",
|
|
13
|
+
"icon.svg",
|
|
14
|
+
"skills",
|
|
15
|
+
"hooks",
|
|
16
|
+
"LICENSE"
|
|
17
|
+
],
|
|
18
|
+
"publishConfig": {
|
|
19
|
+
"access": "public"
|
|
20
|
+
}
|
|
21
|
+
}
|
package/plugin.json
ADDED
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
{
|
|
2
|
+
"description": "Agent development on PenguinHarness: build on the SDK, call any model through one unified LLM API, manage models and secrets, and orchestrate agents, sessions, costs and schedules.",
|
|
3
|
+
"description_zh": "基于 PenguinHarness 的智能体开发:用 SDK 构建应用、经统一的 LLM API 调用任意模型、管理模型与密钥、编排智能体/会话/成本/定时任务。",
|
|
4
|
+
"short_description": "SDK, unified LLM API, config and orchestration.",
|
|
5
|
+
"short_description_zh": "SDK、统一 LLM API、配置与编排。",
|
|
6
|
+
"version": "2026-09-02.1",
|
|
7
|
+
"category": "ai-app-development"
|
|
8
|
+
}
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: penguin-config
|
|
3
|
+
description: Manage model API keys, default models and per-agent vault secrets with the penguin CLI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Penguin Config (CLI)
|
|
7
|
+
|
|
8
|
+
The `penguin` CLI manages model credentials, default models and per-agent vault secrets. Its primary job is model configuration: `penguin config model add` registers a model and `penguin config model list` shows the models currently available. Configuration goes through the CLI only — never read or hand-edit the underlying hidden files.
|
|
9
|
+
|
|
10
|
+
## Before you start
|
|
11
|
+
|
|
12
|
+
If the user's message only invokes this skill (e.g. "use penguin-cli skill") without a concrete request, ask the user what they want to configure. Do not run any command until the goal is clear.
|
|
13
|
+
|
|
14
|
+
## Models
|
|
15
|
+
|
|
16
|
+
Add or update a model (upsert by the `(provider, model_id)` pair; re-run with more options to amend an entry):
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
penguin config model add --provider <group> --model-id <upstream_id> [--api-key <key>] [--base-url <url>] \
|
|
20
|
+
[--client-type <type>] [--context-window <n>] [--max-tokens <n>] [--vision | --no-vision] \
|
|
21
|
+
[--price-cache-read <n>] [--price-cache-write <n>] [--price-output <n>] \
|
|
22
|
+
[--project-id <id>] [--root <dir>] [--set-default]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
- A model is identified by the `(provider, model_id)` pair, so `--provider` and `--model-id` are **both required** — the group is never inferred from the model id, because gateways resell vendor models under their upstream ids and a wrong guess would send the key to another vendor's endpoint. `--model-id` takes the provider's upstream model id (what the API expects) and is persisted as the entry's request id, so it reaches the API unchanged; `--provider` names the group (`deepseek`, `openai`, `anthropic`, `google`, `openrouter`, `siliconflow`, … — `custom` for any other endpoint).
|
|
26
|
+
- For any OpenAI chat-completion compatible endpoint use `--client-type openai --base-url <endpoint>`; omit `--client-type` to auto-route by model id.
|
|
27
|
+
- Prices are USD per million tokens (cache read / cache write / output).
|
|
28
|
+
- `--vision` / `--no-vision` mark whether the model accepts images; omitting both keeps the current value (default is vision-capable).
|
|
29
|
+
- `--max-tokens <n>` pins a per-model output cap (positive integer), overriding the Agent's `model.max_tokens`; omit to inherit. Lower it for small-context models — the per-Agent default (32000) cannot fit into e.g. a 32k context window together with any prompt.
|
|
30
|
+
- All `penguin config model ...` and `penguin config vault ...` commands accept `--root <dir>` to target another data root (default `PENGUIN_HOME`, then `~/.penguin/data`). Two configuration targets — treat the difference as a hard rule:
|
|
31
|
+
- **Penguin's own model** (self-configuration: the model Penguin itself runs on): the default root without `--root` is correct.
|
|
32
|
+
- **An AI app you are building**: `--root` **must** point at the app's own data directory inside the project (e.g. `--root ./penguin_data`, the same path the app gives `createAgent({ root })`) unless the user explicitly chose another location — never write an app's models or keys into the global `~/.penguin/data`, which belongs to the person running Penguin, not to the app.
|
|
33
|
+
- While developing an app, review regularly: `penguin config model list --root <app root>` should show the app's entries, and the global list (no `--root`) should stay clean.
|
|
34
|
+
|
|
35
|
+
Other model commands:
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
penguin config model default --model-id <upstream_id> --provider <group> [--root <dir>] # set the project default model
|
|
39
|
+
penguin config model vision --model-id <upstream_id> --provider <group> [--root <dir>] # set the project vision model (reads images for text-only sessions)
|
|
40
|
+
penguin config model list [--root <dir>] # list models; api_key is shown masked
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Vault (per-agent secrets)
|
|
44
|
+
|
|
45
|
+
The vault holds an agent's environment-variable secrets (third-party API keys etc.); values are injected into that agent's shell subprocesses:
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
penguin config vault set --key <NAME> --value <value> [--project-id <id>] [--agent-id <id>] [--root <dir>]
|
|
49
|
+
penguin config vault list [--project-id <id>] [--agent-id <id>] [--root <dir>] # values are shown masked
|
|
50
|
+
penguin config vault remove --key <NAME> [--project-id <id>] [--agent-id <id>] [--root <dir>]
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
- `--project-id` defaults to `default_project`, `--agent-id` to `default_agent`.
|
|
54
|
+
- Key names follow shell variable rules (letter or underscore first, then letters, digits and underscores); values are limited to 8192 characters.
|
|
55
|
+
|
|
56
|
+
## Language
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
penguin config lang <en|zh> # persist the CLI language via PENGUIN_LANG in your shell rc
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
## Running agents
|
|
63
|
+
|
|
64
|
+
`penguin run -m "<task>" [--provider <group> --model-id <id>] [--agent-id <id>] [--workspace <path>] [--approve <mode>]` runs one task; `penguin chat [--resume [session_id]]` starts or resumes an interactive chat with the same options. The model reference stays a pair here too: pass `--provider` and `--model-id` together, or neither to run on the project's default model — one without the other is rejected.
|
|
65
|
+
|
|
66
|
+
## Storage
|
|
67
|
+
|
|
68
|
+
Paths use `<app_data_dir>`, the App Data Dir value from your Environment section.
|
|
69
|
+
|
|
70
|
+
- `<app_data_dir>/.project_config.toml` — the project's single hidden config file: model list, settings and per-model credentials (`api_key` etc. inlined in each model entry). Configuration is CLI-only — never read, print or hand-edit this file.
|
|
71
|
+
- `<app_data_dir>/agents/<agent_id>/agent_state/.vault.toml` — that agent's vault entries, hidden file; same rule, manage it with `penguin config vault`.
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: penguin-orchestration
|
|
3
|
+
description: Drive PenguinHarness itself from a shell — list and create agents and sessions, send and steer messages mid-flight, and query costs and scheduled tasks via the penguin CLI over the local server.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Penguin Orchestration
|
|
7
|
+
|
|
8
|
+
The `penguin` CLI is a thin client of the PenguinHarness server. Inside a harness agent session it reaches the same server that is running you, so you can orchestrate the platform yourself: list and create agents, start conversations with them, steer those conversations while they run, and query costs and scheduled tasks.
|
|
9
|
+
|
|
10
|
+
## Before you start
|
|
11
|
+
|
|
12
|
+
If the user's message only invokes this skill (e.g. "use penguin-orchestration skill") without a concrete request, ask the user what they want to orchestrate. Read-only commands (`project ls`, `agent ls`, `ls`, `logs`, `cost`, `schedule ls`) are always safe; do not create agents, start sessions or send messages until the goal is clear.
|
|
13
|
+
|
|
14
|
+
## How the connection works
|
|
15
|
+
|
|
16
|
+
- **Inside a harness agent session** (you, now): every command subprocess has `PENGUIN_API_URL`, `PENGUIN_API_TOKEN`, `PENGUIN_PROJECT_ID`, `PENGUIN_AGENT_ID` and `PENGUIN_SESSION_ID` injected, so `penguin` commands automatically reach your own server with your project and agent as the defaults — no login step.
|
|
17
|
+
- **Outside an agent** (a human shell): the CLI attaches to the running local server via its lock file, or auto-starts one; the local `<data-root>/api-token` file (0600) authenticates it.
|
|
18
|
+
- You are operating the same server that runs you: sessions and agents you create appear live in the web UI, where the user sees and owns everything you spawn.
|
|
19
|
+
- The injected token is admin-equivalent. Act accordingly: stick to what the task requires, and prefer read-only commands until a mutation is clearly needed.
|
|
20
|
+
|
|
21
|
+
## Orient first
|
|
22
|
+
|
|
23
|
+
Before mutating anything, see what exists:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
penguin project ls # projects on this server
|
|
27
|
+
penguin agent ls # agents in the current project
|
|
28
|
+
penguin ls --json # the project's sessions, with running state
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
`--json` on any listing gives machine-parseable output.
|
|
32
|
+
|
|
33
|
+
## Command surface
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
penguin run -m <msg> [--project-id <id>] [--agent-id <id>] [--workspace <path>]
|
|
37
|
+
[--model-id <id> --provider <p>] [--approve <mode>] [--thinking <level>]
|
|
38
|
+
[--session <session_id>] [--background] [--timeout <duration>]
|
|
39
|
+
[--goal [budget]] [--json]
|
|
40
|
+
penguin ls [--project-id <id>] [--agent-id <id>] [--days <n>] [-a|--all] [--json]
|
|
41
|
+
penguin input [session_id] [-m <text>] [--timeout <duration>]
|
|
42
|
+
[--project-id <id>] [--agent-id <id>] [--json] [--server <url>]
|
|
43
|
+
penguin logs [session_id] [--project-id <id>] [--agent-id <id>] [--tail <n>]
|
|
44
|
+
[-f|--follow] [--timeout <duration>] [--json]
|
|
45
|
+
penguin agent ls [--project-id <id>] [--json]
|
|
46
|
+
penguin agent create --agent-id <id> [--name <s>] [--description <s>] [--skills <a,b>]
|
|
47
|
+
[--project-id <id>] [--json]
|
|
48
|
+
penguin project ls [--json]
|
|
49
|
+
penguin cost [--days <n>] [--from <d> --to <d>] [--by date|agent|model|session]
|
|
50
|
+
[--project-id <id>] [--agent-id <id>] [--json]
|
|
51
|
+
penguin schedule ls [--project-id <id>] [--agent-id <id>] [--json]
|
|
52
|
+
penguin schedule add <name> --prompt <s> --start-at <ISO|now> [--period <duration>]
|
|
53
|
+
[--end-at <ISO>] [--session-id <id> | --workspace <path>
|
|
54
|
+
[--model-id <id> --provider <p>]] [--disabled]
|
|
55
|
+
[--project-id <id>] [--agent-id <id>]
|
|
56
|
+
penguin schedule update <name> [<same field flags>] [--enable|--disable]
|
|
57
|
+
[--project-id <id>] [--agent-id <id>]
|
|
58
|
+
penguin schedule rm <name> [--project-id <id>] [--agent-id <id>]
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
- `run` starts a task and waits, rendering the conversation, unless `--background` — then it prints the new session id and exits while the server keeps running the task. `--session <session_id>` runs the task in an existing session instead of creating one; the model reference is the `--provider` + `--model-id` pair (both or neither); `--goal [budget]` runs in goal mode — the session loops until the agent declares the goal complete, with an optional spend budget.
|
|
62
|
+
- **Caller-context defaults.** Inside a harness agent, a session-creating `run` fills every field you leave unspecified from your own live session, per field independently: `--workspace`, the `--model-id`/`--provider` pair, `--approve` and `--thinking` inherit the caller's values — the same convention as `run_subagent` parent inheritance. Precedence: explicit flag > caller value > plain fallback (cwd, the Project default model, `allow-all`, none — used wholesale if the caller lookup fails, with a dim stderr note). So inside an agent, `penguin run -m "..."` alone typically does the right thing; pass flags only to diverge.
|
|
63
|
+
- `--timeout <duration>` (`30s`, `5m`, `2h`, or bare seconds) bounds the wait of a foreground `run`, an `input`, or a `logs -f`. Expiry is a soft yield, not an error: the command exits 0 while the task keeps running server-side, printing a still-running note that names the follow-up commands (`--json` prints `{sessionId, status: "running", text}` with the text so far). `--timeout 0` (also `0s`) returns immediately after delivery — the same note without collected text (`--json`: `{sessionId, status: "running"}`); on a bare poll it snapshots a running session instantly. `run --background` stays the idiomatic fire-and-forget for new tasks and rejects `--timeout`; `logs --timeout` requires `-f`.
|
|
64
|
+
- `input` with `-m` steers a **running** session mid-turn (the agent absorbs it as a course correction within the current task) or starts a new turn on an idle one; it waits for the reply unless a `--timeout` bounds the wait (`--timeout 0` = deliver and return at once). Bare `input [session_id]` (no `-m`) **polls**: it prints the session's most recent complete assistant text — an idempotent snapshot that skips user/thinking/tool output and never touches approvals, mirroring `input_subagent`'s empty-prompt semantics. A running session is waited on first (bounded by `--timeout`, else indefinitely); a session with no reply yet prints `(no assistant reply yet)`. `--json` reports `{sessionId, status, text}` — `idle`/`running` when polling, `completed`/`aborted`/`running` with `-m`.
|
|
65
|
+
- `ls` spans every agent of the project, newest first (by last active); archived sessions are left out unless `-a`/`--all` includes them, and `--days <n>` keeps only sessions last active since local midnight n−1 days ago — today counts as day 1, so `--days 2` is yesterday and today, `--days 7` this week. `logs` renders a session's transcript: `--tail <n>` for the last entries, `-f` to follow live.
|
|
66
|
+
- Session ids embed their creation timestamp — `session-YYYY-MM-DD-HH-mm-ss-<8hex>`. Every `<session_id>` argument takes any unique substring of an id; the 8-hex tail is the recommended short form, and an ambiguous fragment errors listing the candidates. On `input` and `logs`, `--project-id` scopes that fragment search (unnecessary with a full id).
|
|
67
|
+
- On `input` and `logs` the id is optional altogether: omitted, it is the agent's most recent session, off the same newest-first listing `chat --resume` uses, with `--agent-id` picking whose. The chosen id is announced as a dim `[latest]` line on stderr, so the target is never ambiguous and `--json` on stdout stays parseable. Bare `penguin logs` is therefore "what just happened" and bare `penguin input` is "what did my agent last say"; an agent with no session at all gets one line pointing at `penguin run` and a non-zero exit.
|
|
68
|
+
|
|
69
|
+
## Recipes
|
|
70
|
+
|
|
71
|
+
### Yesterday's or this week's sessions, with their latest replies
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
penguin ls --days 2 --json # yesterday + today (today counts as day 1)
|
|
75
|
+
penguin ls --days 7 --json # this week; add -a to include archived sessions
|
|
76
|
+
penguin input <session_id> # one session's latest complete assistant reply
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
- `--days <n>` keeps sessions last active since local midnight n−1 days ago. For strictly-yesterday, take `--days 2` and drop today's entries client-side — ids embed the creation date and the JSON carries last-active.
|
|
80
|
+
- Bare `input` prints the latest reply; add `--timeout 0` to snapshot a running session instantly instead of waiting for its turn to finish.
|
|
81
|
+
|
|
82
|
+
### Summarize this week's history in a new session
|
|
83
|
+
|
|
84
|
+
A fresh session gets a fresh context window for the summary; feed it through a file, not the prompt:
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
penguin ls --days 7 --json # pick the sessions
|
|
88
|
+
penguin logs <session_id> --tail 100 # gather each transcript (widen if cut short)
|
|
89
|
+
# write what you gathered into a workspace file with your file tools, then:
|
|
90
|
+
penguin run -m "Read ./weekly-material.md and write the weekly summary to ./weekly-summary.md"
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
- **Exchange big material through workspace files.** Caller-context defaults mean the new session shares your workspace — write the gathered transcripts to `./weekly-material.md` and have the new session read it there. Pages of transcript do not belong in `-m`.
|
|
94
|
+
- Read the result from `./weekly-summary.md` (the foreground run also renders the reply).
|
|
95
|
+
|
|
96
|
+
### Create an agent and say hello
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
penguin agent create --agent-id greeter --name "Greeter" --description "Welcomes people"
|
|
100
|
+
penguin run --agent-id greeter -m "Hello! Introduce yourself."
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
- Agent ids must match `^[a-z][a-z0-9_]{1,63}$`: a lowercase letter first, then lowercase letters, digits and underscores — no hyphens.
|
|
104
|
+
- A newly created agent starts with **no skills preinstalled**: seed it at creation with `--skills a,b` (library names) — include `penguin-orchestration` itself when the new agent must drive the harness too.
|
|
105
|
+
- `--agent-id` switches only the agent: workspace, model, approval and thinking still inherit from your own session (caller-context defaults) — add those flags to change them too. Each `run` without `--session` opens a fresh session; reuse a session id to continue a conversation.
|
|
106
|
+
|
|
107
|
+
### Summarize each agent's costs in a new session
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
penguin cost --days 7 --by agent --json # who spent what this week
|
|
111
|
+
penguin run -m "Summarize this per-agent cost report and flag anomalies: <the JSON>"
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
- The default `penguin cost` card already carries today / last 7 days / total; `--by date|model|session` and `--from <d> --to <d>` give the other cuts, `--project-id` / `--agent-id` narrow the scope.
|
|
115
|
+
- A `--by agent` report is small enough to inline in `-m`; for long breakdowns (`--by session` over a busy week), use the file-exchange pattern from the weekly-summary recipe.
|
|
116
|
+
|
|
117
|
+
### Set up a scheduled task for the current agent
|
|
118
|
+
|
|
119
|
+
```bash
|
|
120
|
+
penguin schedule add build-watch --prompt "Check the build results and report the failures" \
|
|
121
|
+
--start-at now --period 12h --session-id "$PENGUIN_SESSION_ID" \
|
|
122
|
+
--end-at <ISO instant> # only when the request has a horizon
|
|
123
|
+
penguin schedule add daily-report --prompt "Summarize yesterday's conversations" \
|
|
124
|
+
--start-at now --period 1d # no target: a fresh session per firing
|
|
125
|
+
penguin schedule ls # verify
|
|
126
|
+
penguin schedule update daily-report --period 12h # adjust; --enable/--disable to toggle
|
|
127
|
+
penguin schedule rm daily-report # remove — no confirmation prompt
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
- `--agent-id` defaults to yourself from the caller env, so this schedules the current agent. `--start-at` takes ISO 8601 or `now`; `--period` is at least 5m (`30m`/`12h`/`1d`/`7d`), omit it for a one-shot; `--end-at` bounds recurrence. Target the session you are in — `--session-id "$PENGUIN_SESSION_ID"` — unless the user asked for somewhere else: the prompt then arrives in this conversation, with its context. Leave the target off when the user wants a separate session, or when the task is better off starting clean (a nightly report that should not inherit this conversation); each firing then opens a new session, which `--workspace <path>` and the `--model-id` + `--provider` pair configure.
|
|
131
|
+
- `add` creates the schedule **enabled** (`--disabled` stages it off) — deliberately diverging from the raw file, where `enabled` defaults to false. `update` is read-modify-write: unspecified fields keep their stored values, and switching the target form clears the other one.
|
|
132
|
+
- In `schedule ls`, read: the AGENT column (without `--agent-id` the listing spans agents), `enabled` (a disabled entry never fires), `startAt` (first firing), `period` (absent means one-shot), the target — an existing session versus a new session per firing — and `lastFiredAt`.
|
|
133
|
+
- The CLI writes through the schedules API, so mistakes are rejected synchronously. The TOML file stays the single source of truth — `<app_data_dir>/agents/<agent_id>/agent_state/schedule/<name>.toml`, fields mirroring the flags (`prompt`, `enabled` — false by default in the file, `start_at`, `period`, `end_at`, `session_id` / `workspace`+`provider`+`model_id`) — and remains editable with file tools; your system prompt's schedule roster lists yours. A hand edit is only validated by the periodic reconcile (roughly every 30s), with errors landing in error records rather than your terminal — prefer the CLI.
|
|
134
|
+
|
|
135
|
+
### Run a conversation in the background and steer it mid-flight
|
|
136
|
+
|
|
137
|
+
Two patterns; both leave you free while the conversation runs.
|
|
138
|
+
|
|
139
|
+
**(a) Background CLI process — you get a completion report.** Run the CLI itself as a background command: `exec_command` with `run_in_background: true` and the command
|
|
140
|
+
|
|
141
|
+
```bash
|
|
142
|
+
penguin run --agent-id <agent_id> -m "<long task>"
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
- The harness delivers a `[background_task_done]` report when the CLI exits — no polling needed for completion.
|
|
146
|
+
- Meanwhile, find the session with `penguin ls --json` (it shows as running, with the newest id) and steer it: `penguin input <session_id> -m "Focus on X; skip Y" --timeout 0` (deliver and return at once).
|
|
147
|
+
- Poll the latest answer with bare `penguin input <session_id> --timeout 30s` — a bounded wait that exits 0 with a still-running note when the reply is not in yet — or read the raw transcript with `penguin logs <session_id> --tail 20`.
|
|
148
|
+
|
|
149
|
+
**(b) Server-side background — survives you.** `penguin run --background --agent-id <agent_id> -m "<long task>"` prints the session id and exits; the server keeps running the task with no local process.
|
|
150
|
+
|
|
151
|
+
- Poll the latest answer with bare `penguin input <session_id> --timeout 30s`, watch live with `penguin logs <session_id> -f`, and check running state with `penguin ls --json`; steer with `penguin input <session_id> -m ...` the same way.
|
|
152
|
+
|
|
153
|
+
Prefer (a) when you stay around for the result — the completion report comes to you. Prefer (b) when the work must survive your own session ending, or when fanning out many tasks without holding a process per task. A bounded foreground run is the middle ground: `penguin run --timeout 5m -m "..."` renders up to the bound, then soft-yields with the task still running — pick up the answer later with a bare `penguin input <session_id>`.
|
|
154
|
+
|
|
155
|
+
## Cautions
|
|
156
|
+
|
|
157
|
+
- **One active task per session.** `penguin input` at a busy session steers the running task rather than starting a second one; a new task sent at a busy session waits its turn. For parallel work, start parallel sessions.
|
|
158
|
+
- **Unattended sessions must not need a human.** A spawned session inherits your approval mode (`allow-all` when there is no caller to inherit from); if you yourself run under `always-ask`, pass `--approve allow-all` (trusted work) or `--approve read-only` explicitly — an unattended `always-ask` session hangs waiting for approval in the web UI.
|
|
159
|
+
- **No runaway loops.** An agent that messages itself — directly, through a chain of agents, or through a schedule aimed back at its own session — keeps spending until someone stops it. Make every automated conversation terminate: a recurring schedule pointed at your own session takes an `--end-at` whenever the request has a natural horizon (or no `--period` at all, for a one-time reminder), and a prompt whose per-firing work stays small — that session's context grows with every firing. When the user wants it open-ended, leave `--end-at` off and tell them it runs until they remove it.
|
|
160
|
+
- **Spawned work bills the project.** Everything you start lands in the same project's usage (`penguin cost` shows it); a fan-out of sessions multiplies spend.
|
|
161
|
+
- **Configuration stays CLI-managed.** Never read or hand-edit `.project_config.toml` or `agent_state/.vault.toml` — models and secrets go through `penguin config` (see the penguin-cli skill).
|
|
@@ -0,0 +1,359 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: penguin-sdk
|
|
3
|
+
description: Use whenever the user wants to build an agent application — their own program with an embedded agent, such as an AI app, an agentic app or a RAG app. This is writing application code on the Penguin Harness SDK, not configuring an Agent State inside PenguinHarness. Covers self-contained projects, the createSession/run streaming loop with thinking and image messages, wiring the user's existing tools in as CLI commands, and a complete RAG recipe that ingests documents into a knowledge base and answers with citations behind a web UI.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Penguin Harness SDK
|
|
7
|
+
|
|
8
|
+
`@prismshadow/penguin-core` is the TypeScript SDK this agent itself runs on. Use it to build your own AI apps:
|
|
9
|
+
|
|
10
|
+
- An **Agent** loads its state (prompts, tools, skills) from `<root>/<project_id>/agents/<agent_id>/`. Creating an Agent whose directory is empty initializes it with defaults.
|
|
11
|
+
- A **Session** is one conversation of an Agent inside a **Workspace** directory.
|
|
12
|
+
- `session.run()` executes one task and streams every step (thinking, text, tool calls) as OmniMessages.
|
|
13
|
+
|
|
14
|
+
To have an agent perform a task, use the `run_subagent` tool — the SDK is for building applications, not for invoking agents.
|
|
15
|
+
|
|
16
|
+
## Before you start
|
|
17
|
+
|
|
18
|
+
If the user's message only invokes this skill (e.g. "use penguin-sdk skill") without a concrete app to build, ask the user what they want to build. But when the request names a concrete goal — even a single sentence like "build a RAG app that answers questions about these docs" — do **not** ask follow-up questions: build it end to end with the defaults in this skill (self-contained workspace project, project default model, BM25 retrieval, web UI styled per the web-design skill) and list the assumptions you made in your final reply.
|
|
19
|
+
|
|
20
|
+
## Project location
|
|
21
|
+
|
|
22
|
+
Create the app in the current workspace directory by default (the `CWD` value from your Environment section), as a self-contained project — do not place it under `<app_data_dir>` (PenguinHarness's app data root) or depend on any path outside the project folder. When creating the app's agent, the data root defaults **under the working directory (CWD)** too: point `createAgent({ root })` at a directory inside the project, resolved from the source file so it stays relative:
|
|
23
|
+
|
|
24
|
+
```ts
|
|
25
|
+
const agent = await createAgent({ root: path.join(import.meta.dirname, "penguin_data") });
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
With every reference relative to the project, the user can move or copy the folder anywhere and it still runs.
|
|
29
|
+
|
|
30
|
+
## Keys and the data root — check before you build
|
|
31
|
+
|
|
32
|
+
**The app's Penguin data root must live inside the CWD workspace — never `~/.penguin`.** Point `createAgent({ root })` and every `penguin config ... --root <dir>` at a directory under the current working directory (e.g. `./penguin_data`); the global `~/.penguin` belongs to the person running Penguin and must never hold — or lend — the app's config or keys.
|
|
33
|
+
|
|
34
|
+
**Credential first, code second** — a finished app that cannot answer is a failed delivery discovered too late. Before writing any code:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
env | grep -oE "(DEEPSEEK|OPENAI|ANTHROPIC|GEMINI)_API_KEY" || echo none
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
**Only two sources count as a usable credential**: a vault-injected environment variable (the check above; vault keys also appear in your Vault Keys section), or a key already configured in the app's own data root (`penguin config model list --root <data_dir>`). Keys in the global `~/.penguin` or any other `.penguin` directory do **not** count — a bare `penguin config model list` (no `--root`) reads the global store, because the CLI defaults to the global root unless `--root` is given, so a key showing up there proves nothing for the app and must never be used or copied.
|
|
41
|
+
|
|
42
|
+
If neither counted source yields a key, **stop immediately and ask the user to configure one — do not start building, and do not burn turns re-checking in a loop**: have them open this agent's settings via the **gear icon** on its card (left side, Agents page) and add a model API key (e.g. `DEEPSEEK_API_KEY`) in the **key vault** tab — vault values reach your shell environment on the next task. One clear check, then hand back to the user. Build only after a credential is confirmed, or after clearly agreeing with the user to build now and verify later. Model ids to offer the user come from the penguin CLI catalog (`penguin config model add --help`) and the agenthub-models skill's id table.
|
|
43
|
+
|
|
44
|
+
## Setup
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
npm install @prismshadow/penguin-core tsx
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
If the package is not on your npm registry (it is developed in the PenguinHarness monorepo and may not be published), develop inside a checkout of the PenguinHarness repo instead: add your app as a workspace package under `packages/`, depend on `"@prismshadow/penguin-core": "workspace:*"`, then `pnpm install && pnpm build` at the repo root. Tell the user which route you took.
|
|
51
|
+
|
|
52
|
+
Configure a model for the app's data root, in this order — stop at the first that works:
|
|
53
|
+
|
|
54
|
+
1. `penguin config model add --root <data_dir> --provider <group> --model-id <id> --api-key <key> [--base-url <url>] [--client-type openai-chat] --set-default` — prefer `--client-type openai-chat --base-url <endpoint>` (works with any OpenAI Chat Completions compatible endpoint; exact ids in the agenthub-models skill). `--provider` is required: a model is always the `(provider, model_id)` pair and the group is never inferred from the id (`custom` for an endpoint outside the built-in groups).
|
|
55
|
+
2. Environment variables cover the **credential only** (`DEEPSEEK_API_KEY`, `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, …) — model selection still comes from the project config, whose preset default is `deepseek-v4-flash-vision-exp`. Env-only setup therefore works out of the box only with `DEEPSEEK_API_KEY`; for another vendor either run the CLI command above or pass a configured `{ provider, modelId }` pair to `createSession`.
|
|
56
|
+
|
|
57
|
+
Keep model API keys **project-local**: configure them with the penguin CLI into the app's own data root under the working directory, so the project stays self-contained and movable. When building an AI app, **always pass `--root <data_dir>` pointing at the app's data directory inside the current working directory** (the same path you give `createAgent({ root })`, e.g. `./penguin_data`) — never run `penguin config ...` without `--root`, or it writes to the global `~/.penguin/data` instead of the project. Never read, copy or fall back to model keys stored in the user's global `~/.penguin` directory — that config belongs to the person running Penguin, not to the app you are building.
|
|
58
|
+
|
|
59
|
+
Model config lives in one hidden file under the data root's project directory: `.project_config.toml`. It is CLI-only — never read, print or edit it.
|
|
60
|
+
|
|
61
|
+
If the user agreed to build before a credential exists, do not fake the verification: finish the build, report it as **unverified**, and point them at the key vault flow above — once a key is added, vault values reach your environment on the next task and you can run the self-test to completion.
|
|
62
|
+
|
|
63
|
+
## Streaming loop
|
|
64
|
+
|
|
65
|
+
The raw `run()` stream mixes model, event and session-meta payloads — always narrow with the exported guards (`isModelMessage`, `isCompleteModelMessage`, `isEventMessage`) before touching `payload.type`; accessing `msg.payload.type` directly does not typecheck.
|
|
66
|
+
|
|
67
|
+
```ts
|
|
68
|
+
import path from "node:path";
|
|
69
|
+
import readline from "node:readline/promises";
|
|
70
|
+
import { createAgent, isModelMessage, userText } from "@prismshadow/penguin-core";
|
|
71
|
+
|
|
72
|
+
const agent = await createAgent({ root: path.join(import.meta.dirname, "penguin_data") });
|
|
73
|
+
const session = await agent.createSession({ workspaceDir: process.cwd() });
|
|
74
|
+
|
|
75
|
+
const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
|
|
76
|
+
for (;;) {
|
|
77
|
+
const line = await rl.question("> ");
|
|
78
|
+
if (!line.trim()) break;
|
|
79
|
+
// One run per user turn; the same Session keeps the conversation context.
|
|
80
|
+
for await (const msg of session.run([userText(line)], {
|
|
81
|
+
approve: async () => "allow", // demo only — a real app should ask its user ("deny" blocks the call)
|
|
82
|
+
})) {
|
|
83
|
+
if (isModelMessage(msg)) {
|
|
84
|
+
const p = msg.payload;
|
|
85
|
+
if (p.type === "partial_text" && p.event_type === "delta") process.stdout.write(p.text);
|
|
86
|
+
// CoT stream from reasoning models — show progress, but keep it out of the answer channel.
|
|
87
|
+
if (p.type === "partial_thinking" && p.event_type === "delta") process.stderr.write(p.thinking);
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
process.stdout.write("\n");
|
|
91
|
+
}
|
|
92
|
+
rl.close();
|
|
93
|
+
session.dispose();
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
- `createSession({ workspaceDir, provider, modelId })` — `workspaceDir` must already exist (omit for a temporary workspace); the model reference is the `(provider, modelId)` pair, so pass both to pick a configured model or neither for the project default — passing one alone throws.
|
|
97
|
+
- The `approve` callback gates every tool call; **omitting it denies everything**.
|
|
98
|
+
- `opts.thinkingLevel` (`"none" | "low" | "medium" | "high" | "xhigh" | "max"`) overrides the agent's default (`model.thinking_level` in `system_config.yaml`) for this turn only — raise it for hard questions, drop it for latency-sensitive calls like titling or classification.
|
|
99
|
+
- Session lifetime is the app's memory model: reuse one Session for a stateful chat (context accumulates, as above), create one per request for stateless QA (the RAG recipe below); either way call `session.dispose()` when done to release background processes.
|
|
100
|
+
- An Agent's behavior is edited in its `agent_state/` files (system_config.yaml, AGENTS.md, skills/), not in code.
|
|
101
|
+
|
|
102
|
+
## Thinking and image messages
|
|
103
|
+
|
|
104
|
+
Modern models think before answering and accept images; the stream and the input protocol carry both — use them instead of flattening everything to text.
|
|
105
|
+
|
|
106
|
+
**Thinking (CoT) out.** Reasoning models stream `partial_thinking` (field `thinking`) before any `partial_text`, and a complete `thinking` message follows. Show the stream — a silent 20-second wait reads as a hang — but keep it in its own channel: a collapsible muted block per the web-design skill, auto-collapsed once answer text starts. Never concatenate thinking into the answer, store it as the answer, or cite from it; ignore its `fidelity` field (core's replay bookkeeping). Non-reasoning models simply never emit it — don't reserve UI space.
|
|
107
|
+
|
|
108
|
+
**Images in.** Build image input with `imageUrlMessage` (a web URL or a base64 data URL) beside `userText` in the same `run` input:
|
|
109
|
+
|
|
110
|
+
```ts
|
|
111
|
+
import { imageUrlMessage, userText } from "@prismshadow/penguin-core";
|
|
112
|
+
session.run([userText(question), ...images.map(imageUrlMessage)], { ... });
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
Browser flow: `<input type="file" accept="image/*">` plus paste/drag-drop → `FileReader.readAsDataURL` → POST `{ question, images: [dataUrl] }` → the server maps each entry to `imageUrlMessage`. Reject non-image MIME types and cap size (a data URL rides the context window; a few MB is plenty). Whether the session model actually sees pixels is the model config's `vision` flag (`penguin config model list` prints `vision=Y/-`; set via `--vision/--no-vision` on `model add`, default supported): with `vision=false` the core folds the image into an `[attached image: <path>]` line and the built-in image tools read it through the project's configured `vision_model` (`penguin config model vision --provider <group> --model-id <id> --root <data_dir>`) — the app still works, through a description instead of direct sight.
|
|
116
|
+
|
|
117
|
+
**Other payloads worth handling** (always narrow with the guards first): `partial_tool_call` / `partial_tool_call_output` — surface as an activity line ("running `search`…") in apps that grant tools; `request_end` (event) — a non-`completed` `status` is the error signal (`auth` → ask for a key; `message` carries the failure detail; `retry_in_ms` announces a planned in-run retry, renderable as a countdown); `token_usage` (event) — session-cumulative and last-request counts, if the app shows cost; `compaction_begin` / `compaction_end` (events) — long-lived chats only, show a brief "context being compacted" notice. Everything else is safe to ignore.
|
|
118
|
+
|
|
119
|
+
## Wiring in the user's tools
|
|
120
|
+
|
|
121
|
+
When the app's agent must call the user's existing tools (scripts, internal CLIs, anything with an entry point), integrate them as **CLI commands** first: wrap each one as a small executable inside the project (a script under `tools/`, or the user's own binary), and describe it in the embedded agent's persona / `AGENTS.md` — name, what it does, one usage line. The agent invokes it through the built-in `exec_command` tool, so there is nothing to register: no schema to declare, arguments are flags, stdout is the result, the `approve` callback still gates every invocation, and the same command stays testable by hand.
|
|
122
|
+
|
|
123
|
+
Add an MCP server (`tools.mcpServers` in `system_config.yaml`) only when a CLI wrapper cannot express the integration — a long-lived authenticated connection, or tool schemas the model must see typed. Otherwise the CLI form is the cheaper default and keeps the project self-contained.
|
|
124
|
+
|
|
125
|
+
## RAG knowledge app
|
|
126
|
+
|
|
127
|
+
The default recipe when the user wants an app that answers questions over a document set ("docs QA", "knowledge base", "chat with our docs", "become an expert on X"). The core contributes the agent loop only — retrieval is app code. Default to **lexical BM25**: no extra dependencies, no embedding credential, works offline. (Semantic upgrade: embed chunks via `@prismshadow/agenthub` — see the agenthub-models skill — and rank by cosine; only when an embedding-capable key is configured.)
|
|
128
|
+
|
|
129
|
+
```
|
|
130
|
+
my-app/
|
|
131
|
+
package.json # "type": "module"; scripts: ingest / start
|
|
132
|
+
persona.md # the embedded agent's role — write it per the agent-initialization skill
|
|
133
|
+
ingest.ts # corpus/ → data/index.json; initializes penguin_data/, installs persona
|
|
134
|
+
rag.ts # BM25 retrieval over the chunk index
|
|
135
|
+
server.ts # POST /api/ask streams SSE; serves public/
|
|
136
|
+
public/index.html # chat UI — build it per the web-design skill
|
|
137
|
+
corpus/ # collected source documents
|
|
138
|
+
data/index.json # generated chunk index
|
|
139
|
+
penguin_data/ # agent data root (generated; model config lives here)
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
**Collect** — clone or fetch the sources into `corpus/`, keeping only text formats:
|
|
143
|
+
|
|
144
|
+
```bash
|
|
145
|
+
git clone --depth 1 <repo_url> corpus/<name> # or curl pages into corpus/
|
|
146
|
+
find corpus -type f ! -regex '.*\.\(md\|mdx\|txt\|html?\)$' -delete && rm -rf corpus/*/.git
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
**Ingest** (`ingest.ts`) — split on markdown headings, cap chunk size, write one JSON index; also initialize `penguin_data/`, install the persona and strip the skills the embedded agent doesn't need:
|
|
150
|
+
|
|
151
|
+
```ts
|
|
152
|
+
import fs from "node:fs";
|
|
153
|
+
import path from "node:path";
|
|
154
|
+
import { createAgent } from "@prismshadow/penguin-core";
|
|
155
|
+
|
|
156
|
+
const ROOT = import.meta.dirname;
|
|
157
|
+
const walk = (d: string): string[] =>
|
|
158
|
+
fs.readdirSync(d, { withFileTypes: true }).flatMap((e) =>
|
|
159
|
+
e.isDirectory() ? walk(path.join(d, e.name)) : [path.join(d, e.name)]);
|
|
160
|
+
|
|
161
|
+
const STATE = path.join(
|
|
162
|
+
ROOT, "penguin_data", "default_project", "agents", "default_agent", "agent_state");
|
|
163
|
+
await createAgent({ root: path.join(ROOT, "penguin_data") });
|
|
164
|
+
fs.copyFileSync(path.join(ROOT, "persona.md"), path.join(STATE, "AGENTS.md"));
|
|
165
|
+
// A fresh default_agent is initialized with the whole built-in Skill library, and every installed
|
|
166
|
+
// Skill's metadata is injected into the system prompt of every /api/ask. This app only answers
|
|
167
|
+
// from retrieved context, so remove them: unrelated skill descriptions cost tokens on each
|
|
168
|
+
// question and pull the answer off-topic when one happens to match the wording of a question.
|
|
169
|
+
fs.rmSync(path.join(STATE, "skills"), { recursive: true, force: true });
|
|
170
|
+
|
|
171
|
+
const chunks: { id: number; source: string; heading: string; text: string }[] = [];
|
|
172
|
+
for (const f of walk(path.join(ROOT, "corpus")).filter((f) => /\.(md|mdx|txt|html?)$/i.test(f))) {
|
|
173
|
+
const raw = fs.readFileSync(f, "utf8");
|
|
174
|
+
const text = /\.html?$/i.test(f) ? raw.replace(/<[^>]+>/g, " ") : raw;
|
|
175
|
+
const source = path.relative(ROOT, f);
|
|
176
|
+
let heading = path.basename(f);
|
|
177
|
+
for (const block of text.split(/^(?=#{1,3} )/m)) {
|
|
178
|
+
heading = block.match(/^#{1,3} (.+)/)?.[1] ?? heading;
|
|
179
|
+
for (let i = 0; i < block.length; i += 1500) {
|
|
180
|
+
const piece = block.slice(i, i + 1500).trim();
|
|
181
|
+
if (piece.length > 40) chunks.push({ id: chunks.length, source, heading, text: piece });
|
|
182
|
+
}
|
|
183
|
+
}
|
|
184
|
+
}
|
|
185
|
+
fs.mkdirSync(path.join(ROOT, "data"), { recursive: true });
|
|
186
|
+
fs.writeFileSync(path.join(ROOT, "data", "index.json"), JSON.stringify(chunks));
|
|
187
|
+
console.log(`indexed ${chunks.length} chunks`);
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
**Retrieve** (`rag.ts`) — standard BM25 (k1 = 1.2, b = 0.75); the tokenizer treats each CJK character as a token so Chinese queries work. The corpus-wide statistics (per-chunk term frequencies, document frequencies, average length) never change once the corpus is indexed, so build them **once** in `loadIndex` — a per-query rescan would make every question O(corpus):
|
|
191
|
+
|
|
192
|
+
```ts
|
|
193
|
+
import fs from "node:fs";
|
|
194
|
+
import path from "node:path";
|
|
195
|
+
|
|
196
|
+
export interface Chunk { id: number; source: string; heading: string; text: string }
|
|
197
|
+
export interface Index {
|
|
198
|
+
chunks: Chunk[];
|
|
199
|
+
tf: Map<string, number>[]; // per-chunk term → count
|
|
200
|
+
len: number[]; // per-chunk token length
|
|
201
|
+
df: Map<string, number>; // term → number of chunks containing it
|
|
202
|
+
avg: number; // mean chunk length (BM25 length normalization)
|
|
203
|
+
}
|
|
204
|
+
|
|
205
|
+
const tokenize = (s: string): string[] => s.toLowerCase().match(/[a-z0-9]+|[一-鿿]/g) ?? [];
|
|
206
|
+
|
|
207
|
+
export function loadIndex(): Index {
|
|
208
|
+
const chunks: Chunk[] = JSON.parse(
|
|
209
|
+
fs.readFileSync(path.join(import.meta.dirname, "data", "index.json"), "utf8"));
|
|
210
|
+
const tf: Map<string, number>[] = [];
|
|
211
|
+
const len: number[] = [];
|
|
212
|
+
const df = new Map<string, number>();
|
|
213
|
+
for (const c of chunks) {
|
|
214
|
+
const toks = tokenize(`${c.heading} ${c.text}`);
|
|
215
|
+
const m = new Map<string, number>();
|
|
216
|
+
for (const t of toks) m.set(t, (m.get(t) ?? 0) + 1);
|
|
217
|
+
for (const t of m.keys()) df.set(t, (df.get(t) ?? 0) + 1);
|
|
218
|
+
tf.push(m);
|
|
219
|
+
len.push(toks.length);
|
|
220
|
+
}
|
|
221
|
+
const avg = len.reduce((n, l) => n + l, 0) / Math.max(len.length, 1);
|
|
222
|
+
return { chunks, tf, len, df, avg };
|
|
223
|
+
}
|
|
224
|
+
|
|
225
|
+
export function search(index: Index, query: string, k = 6): Chunk[] {
|
|
226
|
+
const { chunks, tf, len, df, avg } = index;
|
|
227
|
+
const q = [...new Set(tokenize(query))];
|
|
228
|
+
const score = (i: number): number => {
|
|
229
|
+
let s = 0;
|
|
230
|
+
for (const t of q) {
|
|
231
|
+
const f = tf[i]!.get(t) ?? 0;
|
|
232
|
+
if (f === 0) continue;
|
|
233
|
+
const n = df.get(t) ?? 0;
|
|
234
|
+
s += Math.log(1 + (chunks.length - n + 0.5) / (n + 0.5)) *
|
|
235
|
+
(f * 2.2) / (f + 1.2 * (0.25 + (0.75 * len[i]!) / avg));
|
|
236
|
+
}
|
|
237
|
+
return s;
|
|
238
|
+
};
|
|
239
|
+
return chunks.map((_, i) => [score(i), i] as const)
|
|
240
|
+
.filter(([s]) => s > 0).sort((a, b) => b[0] - a[0]).slice(0, k)
|
|
241
|
+
.map(([, i]) => chunks[i]!);
|
|
242
|
+
}
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
**Answer & serve** (`server.ts`) — one Session per request (stateless QA), retrieved chunks numbered into the prompt, deltas streamed over SSE, sources sent as the final event. A pure QA session needs no tool calls — deny every approval; a denied or tool-less turn terminates normally. Do **not** clear the toolset with `tools: { builtin: [] }`: an empty tools array is sent to the provider verbatim and some OpenAI-compatible endpoints reject it with a 400, which surfaces as a silent empty answer. Guard the request boundary — a malformed body must return 400, never reject the async handler (an unhandled rejection takes the whole server down) — and abort the run if the client disconnects mid-answer so you stop generating (and paying) for a page nobody is reading.
|
|
246
|
+
|
|
247
|
+
```ts
|
|
248
|
+
import fs from "node:fs";
|
|
249
|
+
import http from "node:http";
|
|
250
|
+
import path from "node:path";
|
|
251
|
+
import { createAgent, isModelMessage, userText } from "@prismshadow/penguin-core";
|
|
252
|
+
import { loadIndex, search } from "./rag.ts";
|
|
253
|
+
|
|
254
|
+
const ROOT = import.meta.dirname;
|
|
255
|
+
const PUB = path.join(ROOT, "public");
|
|
256
|
+
const agent = await createAgent({ root: path.join(ROOT, "penguin_data") });
|
|
257
|
+
const index = loadIndex();
|
|
258
|
+
const MIME: Record<string, string> = { ".html": "text/html", ".css": "text/css", ".js": "text/javascript" };
|
|
259
|
+
|
|
260
|
+
http.createServer(async (req, res) => {
|
|
261
|
+
res.on("error", () => {}); // a client that vanishes mid-write must not throw an uncaught EPIPE
|
|
262
|
+
if (req.method === "POST" && req.url === "/api/ask") {
|
|
263
|
+
let question: string;
|
|
264
|
+
try {
|
|
265
|
+
let body = "";
|
|
266
|
+
for await (const part of req) body += part; // a mid-body connection reset rejects here — caught below, never fatal
|
|
267
|
+
const parsed = JSON.parse(body) as { question?: unknown };
|
|
268
|
+
if (typeof parsed.question !== "string" || !parsed.question.trim()) throw new Error();
|
|
269
|
+
question = parsed.question;
|
|
270
|
+
} catch {
|
|
271
|
+
res.writeHead(400, { "content-type": "application/json" });
|
|
272
|
+
res.end(JSON.stringify({ error: "expected a JSON body { question: string }" }));
|
|
273
|
+
return;
|
|
274
|
+
}
|
|
275
|
+
const hits = search(index, question);
|
|
276
|
+
const context = hits.map((c, i) => `[${i + 1}] ${c.source} — ${c.heading}\n${c.text}`).join("\n\n");
|
|
277
|
+
const ac = new AbortController();
|
|
278
|
+
res.on("close", () => ac.abort()); // client navigated away → cancel the in-flight generation
|
|
279
|
+
// Create the Session BEFORE committing headers: a model-config failure then returns a real
|
|
280
|
+
// HTTP error instead of an unhandled rejection with a 200 already on the wire.
|
|
281
|
+
let session;
|
|
282
|
+
try {
|
|
283
|
+
session = await agent.createSession({ workspaceDir: ROOT });
|
|
284
|
+
} catch {
|
|
285
|
+
res.writeHead(503, { "content-type": "application/json" });
|
|
286
|
+
res.end(JSON.stringify({ error: "no model configured yet — see the setup steps" }));
|
|
287
|
+
return;
|
|
288
|
+
}
|
|
289
|
+
res.writeHead(200, { "content-type": "text/event-stream", "cache-control": "no-cache" });
|
|
290
|
+
try {
|
|
291
|
+
const prompt = `Answer in plain text (no Markdown; short paragraphs) from the context below; cite blocks inline as [1][2]. If the context is not enough, say so.\n\n${context}\n\nQuestion: ${question}`;
|
|
292
|
+
for await (const msg of session.run([userText(prompt)], { approve: async () => "deny", signal: ac.signal })) {
|
|
293
|
+
if (isModelMessage(msg)) {
|
|
294
|
+
const p = msg.payload;
|
|
295
|
+
if (p.type === "partial_text" && p.event_type === "delta" && !res.writableEnded)
|
|
296
|
+
res.write(`data: ${JSON.stringify({ delta: p.text })}\n\n`);
|
|
297
|
+
// Reasoning models: forward CoT on its own SSE field so the UI can collapse it.
|
|
298
|
+
if (p.type === "partial_thinking" && p.event_type === "delta" && !res.writableEnded)
|
|
299
|
+
res.write(`data: ${JSON.stringify({ thinking: p.thinking })}\n\n`);
|
|
300
|
+
}
|
|
301
|
+
}
|
|
302
|
+
// Sources carry the matched chunk text verbatim: the UI must be able to show the exact
|
|
303
|
+
// block behind each [n], not just a file link.
|
|
304
|
+
if (!res.writableEnded)
|
|
305
|
+
res.write(`data: ${JSON.stringify({ sources: hits.map((c) => ({ source: c.source, heading: c.heading, url: `/${c.source}`, text: c.text })) })}\n\n`);
|
|
306
|
+
} catch {
|
|
307
|
+
// The run failed after headers were sent, or the client left: surface an error event (best effort), then clean up.
|
|
308
|
+
if (!res.writableEnded) res.write(`data: ${JSON.stringify({ error: "generation failed" })}\n\n`);
|
|
309
|
+
} finally {
|
|
310
|
+
session.dispose();
|
|
311
|
+
if (!res.writableEnded) res.end();
|
|
312
|
+
}
|
|
313
|
+
return;
|
|
314
|
+
}
|
|
315
|
+
const pathname = (req.url ?? "/").split("?")[0] ?? "/";
|
|
316
|
+
// /corpus/* serves the source documents read-only, so citation links resolve to real files.
|
|
317
|
+
const inCorpus = pathname.startsWith("/corpus/");
|
|
318
|
+
const base = inCorpus ? path.join(ROOT, "corpus") : PUB;
|
|
319
|
+
const rel = inCorpus
|
|
320
|
+
? pathname.slice("/corpus/".length)
|
|
321
|
+
: pathname === "/"
|
|
322
|
+
? "index.html"
|
|
323
|
+
: pathname.slice(1);
|
|
324
|
+
const file = path.normalize(path.join(base, rel));
|
|
325
|
+
if (file.startsWith(base + path.sep) && fs.existsSync(file) && fs.statSync(file).isFile()) {
|
|
326
|
+
res.writeHead(200, { "content-type": MIME[path.extname(file)] ?? "text/plain" });
|
|
327
|
+
res.end(fs.readFileSync(file));
|
|
328
|
+
} else {
|
|
329
|
+
res.writeHead(404);
|
|
330
|
+
res.end();
|
|
331
|
+
}
|
|
332
|
+
}).listen(Number(process.env.PORT ?? 4630), () => console.log("http://localhost:4630"));
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
**UI** (`public/index.html`) — a chat interface built per the web-design skill: message list, streamed assistant text appended delta by delta (plain text under the output contract below: escape, split blank-line paragraphs, style the `[n]` markers), `thinking` events into the collapsible reasoning block (collapse it when the first answer delta arrives), the final `sources` event rendered as citations (pill chips or accordion source cards), an empty state inviting the first question with **3–4 example questions the corpus can actually answer** (clicking one submits it), and a visible error state when `/api/ask` fails. Citations must satisfy both of these, never bare text:
|
|
336
|
+
|
|
337
|
+
- **Reveal the original chunk**: clicking a citation chip (or an inline `[n]`) opens a popover/panel showing the matched chunk's `text` from the sources event **verbatim** — the numbering maps 1:1 to the context blocks in the prompt, so `[n]` always reveals exactly the block the answer drew on.
|
|
338
|
+
- **Link to the real document**: inside the popover, `<a href="<url>" target="_blank">` using the `url` field (`/corpus/<path>`, which this server serves) — clicking the chip itself opens the popover, the document link lives within it. When the corpus was cloned from a public repository, prefer mapping the path to the canonical upstream page instead (e.g. the GitHub blob URL derived from the clone URL).
|
|
339
|
+
|
|
340
|
+
**Output format and language** — settle both up front, in the persona and the retriever, not in the UI:
|
|
341
|
+
|
|
342
|
+
- **No Markdown pipeline — set the output format instead**: instruct the embedded agent (in `persona.md` and the per-request prompt) to answer in plain text — short paragraphs separated by blank lines, citations as bare `[n]`, no Markdown syntax. The UI then only escapes the text, splits paragraphs and styles the `[n]` markers; there is no renderer to build. When richer structure genuinely matters, have the model emit a small whitelisted HTML subset (`<p> <ul> <li> <strong> <code>`) and sanitize to exactly that whitelist before inserting — never inject unsanitized model output.
|
|
343
|
+
- **Cross-language retrieval**: the corpus and the user often speak different languages (English docs, Chinese questions), and BM25 is purely lexical — a Chinese question scores zero against English chunks. At ingest time derive a small bilingual keyword map for the corpus's core vocabulary (10–20 domain terms, e.g. `权限 → permissions / allow / deny`, `钩子 → hooks`) and expand query tokens through it in `search()` before scoring; keep the per-character CJK tokenizer. The persona already pins the answer language to the question's language.
|
|
344
|
+
|
|
345
|
+
**Persona** (`persona.md`) — the embedded agent's role, written per the agent-initialization skill. Shape: one role sentence ("You are an expert on X; you answer strictly from the provided context blocks"), citation and refusal rules, plain-text output (no Markdown — the output contract above), answer language follows the question.
|
|
346
|
+
|
|
347
|
+
## Verify before you hand over
|
|
348
|
+
|
|
349
|
+
Never declare the app done without running it:
|
|
350
|
+
|
|
351
|
+
1. `npm install` succeeds (or the workspace route builds).
|
|
352
|
+
2. Model configured for `penguin_data` (CLI or env var; no usable key → see Setup: ask the user to add one to this agent's key vault, and report the app as unverified for now).
|
|
353
|
+
3. `npm run ingest` prints `indexed N chunks` with N > 0.
|
|
354
|
+
4. Start `npm start` in the background, then ask a real question:
|
|
355
|
+
`curl -N -sS -X POST localhost:4630/api/ask -H 'content-type: application/json' -d '{"question":"<something the corpus answers>"}'` — expect streamed `data:` deltas ending in a `sources` event that carries `source`, `url` **and the matched chunk `text`** per hit. If nothing streams, the model call failed: re-check step 2 and the provider endpoint before touching the code.
|
|
356
|
+
Then `curl` one of the returned source `url`s — it must return the document, not a 404 (citation links have to resolve).
|
|
357
|
+
5. Open the UI (or screenshot it) to confirm the layout renders.
|
|
358
|
+
|
|
359
|
+
Fix any failure and re-verify; when the app accepts image input, one verification question must include a real image. Report with backtick-wrapped relative paths (`server.ts`, `public/index.html`, …), how to start the app, and the assumptions you made.
|
|
@@ -0,0 +1,196 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: unified-llm-api
|
|
3
|
+
description: Call model APIs through @prismshadow/agenthub — streaming text generation, image generation, speech synthesis, embeddings and the supported-model registry with one client.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Unified LLM API (AgentHub)
|
|
7
|
+
|
|
8
|
+
`@prismshadow/agenthub` is a unified TypeScript client for model APIs: streaming text, image generation, speech synthesis and embeddings behind one entry point.
|
|
9
|
+
|
|
10
|
+
```bash
|
|
11
|
+
npm install @prismshadow/agenthub
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
The main entry point is `AutoLLMClient`:
|
|
15
|
+
|
|
16
|
+
```ts
|
|
17
|
+
import { AutoLLMClient } from "@prismshadow/agenthub";
|
|
18
|
+
|
|
19
|
+
const client = new AutoLLMClient({ model: "<model_id>", apiKey: "<key>", baseUrl: "<url>", clientType: "<type>" });
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
`apiKey`, `baseUrl` and `clientType` are optional (see routing below). The package also exports `listSupportedModels` (the model registry) and the error classes `AgentHubError`, `UnsupportedParameterError`, `EmptyResponseError` and `ToolCallArgumentParseError`.
|
|
23
|
+
|
|
24
|
+
## Before you start
|
|
25
|
+
|
|
26
|
+
If the user's message only invokes this skill (e.g. "use agenthub-models skill") without a concrete task, ask the user what they want to build. Do not write code until the requirement is clear.
|
|
27
|
+
|
|
28
|
+
**Important prerequisite — set the key up first, then develop.** When the script is an AI app you are building for the user, have them add the model API key in **this agent's key vault** (gear icon on its card, Agents page → settings → key vault tab) *before* you start, so the credential is in your shell environment. If the app stores its own model config, keep its Penguin data root **inside the CWD workspace** (`--root ./penguin_data`), never `~/.penguin`. Model ids can come from the penguin CLI catalog and the id table below.
|
|
29
|
+
|
|
30
|
+
Check for a usable API key before writing code — the client needs one for whichever provider you target:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
env | grep -oE "(DEEPSEEK|OPENAI|ANTHROPIC|GEMINI|ZAI|MOONSHOT|MINIMAX)_API_KEY" || echo none
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Vault keys also appear in your Vault Keys section. **Only two sources count as a usable key**: a vault-injected environment variable (the check above), or — when the app stores its own model config — a key already configured in the app's own data root (`penguin config model list --root <data_dir>`). Keys living in the global `~/.penguin` or any other `.penguin` directory do **not** count — a bare `penguin config model list` (no `--root`) reads the global store, because the CLI defaults to the global root unless `--root` is given, so a key showing up there proves nothing for your script and must never be used or copied.
|
|
37
|
+
|
|
38
|
+
If neither counted source yields a usable key, **stop immediately and ask the user to configure one — do not write code, and do not keep calling tools to retry**: ask them to add one in the agent's **key vault** (gear icon on the agent's card, Agents page → settings → key vault tab); vault values reach your shell environment on the next task. Re-checking the environment or the vault in a loop just wastes turns — one clear check, then hand back to the user.
|
|
39
|
+
|
|
40
|
+
Keep model API keys **project-local**: for an app that stores its own model config, write the key into the project under the working directory with the penguin CLI, **always passing `--root <data_dir>` for a directory inside the current working directory** (`penguin config model add --root ./penguin_data --provider <group> --model-id <id> --api-key <key>`) — without `--root` it writes to the global `~/.penguin/data` instead. `--provider` is required alongside `--model-id`: a model entry is the `(provider, model_id)` pair and the group is never inferred (use `custom` for an endpoint outside the built-in groups). Otherwise rely on vault-injected environment variables. Never read, copy or fall back to model keys stored in the user's global `~/.penguin` directory — that config belongs to the person running Penguin, not to your script.
|
|
41
|
+
|
|
42
|
+
## Model IDs
|
|
43
|
+
|
|
44
|
+
Use exact model ids. If an id is not in the table below and the user has not given one, ask the user to confirm the exact id before writing code.
|
|
45
|
+
|
|
46
|
+
| Family | Official IDs | Gateway variants |
|
|
47
|
+
| ---------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
48
|
+
| Gemini 3.7 | `gemini-3.7-flash` | OpenRouter `google/gemini-3.7-flash` |
|
|
49
|
+
| Gemini 3.6 | `gemini-3.6-flash`, `gemini-3.5-flash-lite` | — |
|
|
50
|
+
| Gemini 3 | `gemini-3.1-pro-preview`, `gemini-3.5-flash`, `gemini-3.1-flash-lite` | — |
|
|
51
|
+
| Gemini 3 image | `gemini-3.1-flash-image`, `gemini-3-pro-image-preview` | — |
|
|
52
|
+
| Gemini 3 TTS | `gemini-3.1-flash-tts-preview` | — |
|
|
53
|
+
| Gemini embedding | `gemini-embedding-2` | — |
|
|
54
|
+
| Claude 5 | `claude-fable-5`, `claude-opus-5`, `claude-sonnet-5` | OpenRouter `anthropic/claude-fable-5`, `anthropic/claude-opus-5`, `anthropic/claude-sonnet-5` |
|
|
55
|
+
| Claude 4 | `claude-sonnet-4-6`, `claude-opus-4-7`, `claude-opus-4-8` | OpenRouter `anthropic/claude-opus-4.8`, `anthropic/claude-opus-4.7` |
|
|
56
|
+
| GPT-5.6 | `gpt-5.6` (routes to sol), `gpt-5.6-terra`, `gpt-5.6-luna` | OpenRouter `openai/gpt-5.6-sol`, `openai/gpt-5.6-terra`, `openai/gpt-5.6-luna` |
|
|
57
|
+
| GPT-5.5 / 5.4 | `gpt-5.5`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.4-nano` | OpenRouter `openai/gpt-5.5`, `openai/gpt-5.5-pro`, `openai/gpt-5.4`, `openai/gpt-5.4-mini`, `openai/gpt-5.4-nano`, `openai/gpt-5.4-pro` |
|
|
58
|
+
| OpenAI embedding | `text-embedding-3-small`, `text-embedding-3-large` | — |
|
|
59
|
+
| MiniMax M3 | `MiniMax-M3` | OpenRouter `minimax/minimax-m3` |
|
|
60
|
+
| Kimi K3 | `kimi-k3` | OpenRouter `moonshotai/kimi-k3` |
|
|
61
|
+
| Kimi K2.7 Code | — | SiliconFlow `moonshotai/Kimi-K2.7-Code`; Fireworks AI `accounts/fireworks/models/kimi-k2p7-code` |
|
|
62
|
+
| Kimi K2.6 | `kimi-k2.6` | OpenRouter `moonshotai/kimi-k2.6`; SiliconFlow `Pro/moonshotai/Kimi-K2.6` |
|
|
63
|
+
| DeepSeek V4 | `deepseek-v4-pro`, `deepseek-v4-flash`, `deepseek-v4-flash-vision-exp` | OpenRouter `deepseek/deepseek-v4-pro-0813`, `deepseek/deepseek-v4-pro`, `deepseek/deepseek-v4-flash`, `deepseek/deepseek-v4-flash-0731`, `deepseek/deepseek-v4-flash-vision-exp`; Fireworks AI `accounts/fireworks/models/deepseek-v4-flash-0731`; SiliconFlow `deepseek-ai/DeepSeek-V4-Pro`, `deepseek-ai/DeepSeek-V4-Flash` |
|
|
64
|
+
| GLM 5.3 | `glm-5.3`, `glm-5.3-flash` | OpenRouter `z-ai/glm-5.3`, `z-ai/glm-5.3-flash` |
|
|
65
|
+
| GLM 5.2 | `glm-5.2` | OpenRouter `z-ai/glm-5.2`; SiliconFlow `zai-org/GLM-5.2` |
|
|
66
|
+
| GLM 5.1 | `glm-5.1` | — |
|
|
67
|
+
| Qwen 3.8 Max | — | OpenRouter `qwen/qwen3.8-max` |
|
|
68
|
+
| Qwen 3.8 Flash | — | Qwen DashScope `qwen3.8-flash` |
|
|
69
|
+
| Qwen 3.6 | — | OpenRouter `qwen/qwen3.6-35b-a3b`; SiliconFlow `Qwen/Qwen3.6-35B-A3B` |
|
|
70
|
+
| Inkling | — | OpenRouter `thinkingmachines/inkling`; Fireworks AI `accounts/fireworks/models/inkling` |
|
|
71
|
+
|
|
72
|
+
The image endpoint dropped its preview suffix: `gemini-3.1-flash-image-preview` is deprecated, use `gemini-3.1-flash-image`.
|
|
73
|
+
|
|
74
|
+
`glm-5.3-flash` is the one GLM model that reads images (`@prismshadow/agenthub` >= 0.4.8). The GLM client sends an `image_url` item as an `image_url` part, in a prompt and in a tool result alike, and both an HTTP(S) URL and a base64 data URL pass through unchanged. The version match is case-insensitive, so the gateway spellings `z-ai/glm-5.3-flash` and `zai-org/GLM-5.3-Flash` are recognised too. Every other GLM id refuses an image rather than dropping it — `GLM <id> does not support image inputs.` in a prompt, `GLM <id> does not support images in tool results.` in a tool result — and that includes `glm-5v-turbo`.
|
|
75
|
+
|
|
76
|
+
Gateway model lists can be queried online:
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
curl https://openrouter.ai/api/v1/models
|
|
80
|
+
curl --request GET --url https://api.siliconflow.cn/v1/models --header 'Authorization: Bearer <token>'
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Supported-model registry
|
|
84
|
+
|
|
85
|
+
`listSupportedModels(currency?)` returns the models AgentHub itself knows how to route, so ids, endpoints, modalities, context windows and prices can be read from the package instead of being hardcoded:
|
|
86
|
+
|
|
87
|
+
```ts
|
|
88
|
+
import { listSupportedModels } from "@prismshadow/agenthub";
|
|
89
|
+
|
|
90
|
+
for (const m of listSupportedModels()) {
|
|
91
|
+
console.log(m.model, m.base_url, m.client, m.context_window, m.pricing?.prompt_tokens);
|
|
92
|
+
}
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
- Each `SupportedModel` is `{ model, base_url, client, input_modalities, output_modalities, context_window?, pricing? }`. The `(model, base_url, client)` triple maps straight onto the constructor: `new AutoLLMClient({ model, baseUrl: base_url, clientType: client })`.
|
|
96
|
+
- Modalities are `"Text" | "Image" | "Video" | "Audio" | "Embed"`. Coverage includes the official vendor endpoints plus the OpenRouter and SiliconFlow gateways; `context_window` and `pricing` are omitted where the platform publishes no authoritative value (image and TTS models, for instance).
|
|
97
|
+
- `pricing` is per million tokens, keyed by the same usage buckets as `usage_metadata`: `prompt_tokens` (non-cached input), `thoughts_tokens` / `response_tokens` (both the output price) and optional `cached_tokens` (cache-hit price). Values are stored in USD; pass `listSupportedModels("CNY")` to convert at 7 CNY/USD.
|
|
98
|
+
|
|
99
|
+
The registry is the curated current line-up, so prefer it when picking a model or estimating cost. It is not the routing table, and it lags in both directions: older ids in the table above (`gpt-5.4`, `claude-opus-4-7`, `gemini-3.1-pro-preview`, `gemini-3.1-flash-lite`) still route fine without appearing in it, and a newly launched id can route before the registry carries it. For an id the registry omits, take the context window and price from the vendor's own page.
|
|
100
|
+
|
|
101
|
+
## Routing and credentials
|
|
102
|
+
|
|
103
|
+
- Without `clientType`, the client auto-routes by model id substring, in this order: `minimax-m3` (exact), `gemini-3*` / `gemini-embedding`, `claude` 4-6/4-7/4-8/-5, `gpt-5.4`/`gpt-5.5`/`gpt-5.6`, `glm-5` (whole series, 5.3 included), `kimi-k3`/`kimi-k2.5`/`kimi-k2.6`, `deepseek-v4`, `ant-messages`, `openai-responses`, `openai`+`embedding` (embeddings), `openai` (chat). Ids matching none of these throw. Most gateway variants in the table above hit the same substrings, so they route to the right family — just set `baseUrl` to the gateway endpoint.
|
|
104
|
+
- Three generic protocol clients cover everything else (all take `baseUrl` + `apiKey`):
|
|
105
|
+
- `clientType: "openai-chat"` — any OpenAI Chat Completions compatible endpoint (gateway models, Qwen via OpenRouter/SiliconFlow or DashScope `https://dashscope.aliyuncs.com/compatible-mode/v1`, local vLLM, …). Renamed from `openai` in AgentHub 0.4.2; the bare `openai` string still routes as a deprecated alias.
|
|
106
|
+
- `clientType: "openai-responses"` — OpenAI Responses-compatible endpoints (OpenAI, OpenRouter, DeepSeek, Z.AI, MiniMax all serve one).
|
|
107
|
+
- `clientType: "ant-messages"` — Anthropic Messages-compatible endpoints (Anthropic, OpenRouter `https://openrouter.ai/api`, DeepSeek `https://api.deepseek.com/anthropic`, Z.AI, MiniMax).
|
|
108
|
+
- Exception: an id served by an OpenAI-compatible gateway that still matches a first-party substring (e.g. OpenRouter's `google/gemini-3.7-flash`, `anthropic/claude-sonnet-5` or `openai/gpt-5.6-sol` on the `/api/v1` endpoint) would auto-route to the vendor protocol client — and a dotted id like `anthropic/claude-opus-4.8` matches nothing and throws. Always pass an explicit `clientType` for gateway ids; never rely on the id. Routing reads `clientType` (or the model id) as a plain lowercased string and never looks at `baseUrl`, so the vendor prefix gives no protection.
|
|
109
|
+
- OpenRouter serves both protocols at `https://openrouter.ai/api/v1`, so its `openai/*` ids work with `clientType: "openai-responses"` as well as `"openai-chat"`; use Responses when you want reasoning items round-tripped.
|
|
110
|
+
- The first-party `deepseek-v4` client posts to `{baseUrl}/responses` (AgentHub 0.4.6 moved it off Chat Completions). A self-hosted endpoint serving a `deepseek-v4*` id over Chat Completions must therefore pass `clientType: "openai-chat"` explicitly rather than rely on id routing.
|
|
111
|
+
- API key: constructor parameter first, then the provider environment variable — `DEEPSEEK_API_KEY`, `ANTHROPIC_API_KEY` (also for `ant-messages`), `OPENAI_API_KEY` (also for `openai-chat`/`openai-responses`), `GEMINI_API_KEY`, `ZAI_API_KEY`, `MOONSHOT_API_KEY`, `MINIMAX_API_KEY`. Base URLs read the same names with `_BASE_URL`.
|
|
112
|
+
|
|
113
|
+
## Streaming text
|
|
114
|
+
|
|
115
|
+
```ts
|
|
116
|
+
for await (const event of client.streamingResponseStateful({
|
|
117
|
+
message: { role: "user", content_items: [{ type: "text", text: "Hello" }] },
|
|
118
|
+
config: {},
|
|
119
|
+
})) {
|
|
120
|
+
for (const item of event.content_items) {
|
|
121
|
+
if (item.type === "text") process.stdout.write(item.text);
|
|
122
|
+
}
|
|
123
|
+
}
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
- Each `event` is a `UniEvent`: `event_type` is `start` | `delta` | `stop`, and `content_items` carry the increments.
|
|
127
|
+
- `config` accepts `max_tokens`, `temperature`, `system_prompt`, `thinking_level` (the `ThinkingLevel` enum, `NONE` to `MAX`), `tool_choice`, `prompt_caching`, `fast_mode` and `tools`.
|
|
128
|
+
- `streamingResponseStateful` keeps conversation history inside the client; manage it with `getHistory()` / `setHistory(history)` / `clearHistory()`. The stateless variant is `streamingResponse({ messages, config })`.
|
|
129
|
+
|
|
130
|
+
## Config parameters the model may reject
|
|
131
|
+
|
|
132
|
+
A config value the target client cannot honour throws `UnsupportedParameterError` (an `AgentHubError` carrying `client` and `parameter`) while building the request, before anything reaches the network:
|
|
133
|
+
|
|
134
|
+
```ts
|
|
135
|
+
import { UnsupportedParameterError } from "@prismshadow/agenthub";
|
|
136
|
+
|
|
137
|
+
try {
|
|
138
|
+
// ...
|
|
139
|
+
} catch (err) {
|
|
140
|
+
if (err instanceof UnsupportedParameterError) console.error(err.parameter, err.message);
|
|
141
|
+
}
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
- `thinking_level` never throws: every client maps each level onto the closest one the model supports, and `MAX` (the tier above `XHIGH`, added in AgentHub 0.4.4) degrades silently wherever the vendor has no such tier — Gemini and MiniMax M3 stop at `high`. Kimi K3 reasons unconditionally, so `NONE` degrades to its lowest effort rather than disabling thinking; GLM-5.2 sends `reasoning_effort` alongside its `thinking` block and only `NONE` disables it. GLM-5.3 thinks unconditionally (`NONE` degrades to the light `low` effort) and clamps `reasoning_effort` to `low`/`high`/`max`; `gemini-3.7-*` clamps to `low`/`medium`/`high` (`NONE` degrades to `low`). DeepSeek V4 accepts `low`/`high`/`max` and maps `medium` and `xhigh` onto `high` server-side, so since 0.4.4 `LOW` sends `low` (it sent `high`) and `XHIGH` sends `high` (it sent `max`).
|
|
145
|
+
- `temperature` is rejected outright by Gemini 3.6/3.7 — those generations deprecated the sampling parameters, so the client refuses them instead of sending a value the API ignores. GPT-5.5/5.6, the whole Claude 4.6+ family (4.6 included since AgentHub 0.4.2), DeepSeek V4, Kimi K2.6 and Kimi K3 accept only the protocol default `1.0` and reject any other value. Gemini 3, GLM and the generic protocol clients (`openai-chat` / `openai-responses` / `ant-messages`) pass it through.
|
|
146
|
+
- `tool_choice`: `"auto"` is safe everywhere. Claude accepts a single forced tool name; DeepSeek V4 and Kimi K2.6 allow `"auto"` / `"none"`; Kimi K3 adds `"required"` but refuses a specific tool (K2.x also rejects `"required"`); GLM only accepts `"auto"`.
|
|
147
|
+
- `prompt_caching`: every client accepts `PromptCaching.ENABLE` and rejects the other values — caching is on by default and Kimi K3 caches context automatically.
|
|
148
|
+
- `fast_mode` (`UniConfig`, AgentHub 0.4.2): fast processing at premium pricing. OpenAI-protocol clients (`openai-chat`, `openai-responses`, `gpt-5.6`, `minimax-m3`) map it to `service_tier: "priority"`; Anthropic-protocol clients (`ant-messages`, `claude-5`) map it to `speed: "fast"` with a beta header (an Anthropic research preview limited to Claude Opus 5 / Opus 4.8 — organizations without access get a 429). Clients without a fast tier (Gemini, GLM, Kimi, DeepSeek, embeddings, Claude 4.6 models) raise `UnsupportedParameterError`; DeepSeek and Z.AI's OpenAI-compatible endpoints simply ignore the tier.
|
|
149
|
+
|
|
150
|
+
Leave a parameter unset and the protocol default applies, which is the portable choice when a script must run against several families.
|
|
151
|
+
|
|
152
|
+
## Image generation
|
|
153
|
+
|
|
154
|
+
Use a Gemini image model (see Model IDs) and set `config.image_config` (optional `aspect_ratio`, and `image_size` of `"1K"` | `"2K"`):
|
|
155
|
+
|
|
156
|
+
```ts
|
|
157
|
+
import fs from "node:fs";
|
|
158
|
+
|
|
159
|
+
const client = new AutoLLMClient({ model: "gemini-3.1-flash-image" });
|
|
160
|
+
for await (const event of client.streamingResponseStateful({
|
|
161
|
+
message: { role: "user", content_items: [{ type: "text", text: "A penguin on a glacier" }] },
|
|
162
|
+
config: { image_config: { aspect_ratio: "16:9", image_size: "2K" } },
|
|
163
|
+
})) {
|
|
164
|
+
for (const item of event.content_items) {
|
|
165
|
+
if (item.type === "inline_data") fs.writeFileSync("image.png", item.data);
|
|
166
|
+
}
|
|
167
|
+
}
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
Images arrive as `inline_data` content items (`data` is a Buffer, with `mime_type`).
|
|
171
|
+
|
|
172
|
+
## Speech synthesis
|
|
173
|
+
|
|
174
|
+
Use a Gemini TTS model (`gemini-3.1-flash-tts-preview`) and set `config.tts_config`:
|
|
175
|
+
|
|
176
|
+
```ts
|
|
177
|
+
config: { tts_config: [{ voice: "Kore" }] }
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
- One entry → single voice; two entries → multi-speaker, and each entry must also set `speaker`.
|
|
181
|
+
- The `inline_data` output is raw PCM (24kHz 16-bit mono) — wrap it in a WAV header yourself before saving as `.wav`.
|
|
182
|
+
|
|
183
|
+
## Embeddings
|
|
184
|
+
|
|
185
|
+
Two routes:
|
|
186
|
+
|
|
187
|
+
- Gemini: a model whose id contains `gemini-embedding` auto-routes (`gemini-embedding-2`).
|
|
188
|
+
- Any OpenAI-compatible embeddings endpoint: pass `clientType: "openai-embedding"` (plus `baseUrl` and `apiKey` as needed) — ids like `text-embedding-3-small` / `text-embedding-3-large` match no auto-route substring and would throw without it.
|
|
189
|
+
|
|
190
|
+
Optional `config.embedding_config`:
|
|
191
|
+
|
|
192
|
+
```ts
|
|
193
|
+
config: { embedding_config: { dimensions: 768 } }
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
The output arrives as `embedding` content items (`embedding` is a number array).
|