@botbotgo/agent-harness 0.0.17 → 0.0.18

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.
Files changed (2) hide show
  1. package/README.md +141 -28
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -17,7 +17,7 @@ The public API stays intentionally small:
17
17
 
18
18
  ## Product Overview
19
19
 
20
- Agent Harness loads a workspace from disk, compiles its config into runnable agent bindings, and executes requests through either a lightweight LangChain v1 path or a DeepAgent path.
20
+ Agent Harness loads a workspace from disk, compiles its config into runnable agent bindings, and executes requests through either a lightweight LangChain path or a DeepAgent path.
21
21
 
22
22
  Out of the box, the framework supports:
23
23
 
@@ -48,10 +48,14 @@ Create a workspace with at least:
48
48
  your-workspace/
49
49
  AGENTS.md
50
50
  config/
51
- model.yaml
51
+ models.yaml
52
52
  runtime.yaml
53
- direct.yaml
54
- orchestra.yaml
53
+ agents/
54
+ direct.yaml
55
+ orchestra.yaml
56
+ resources/
57
+ package.json
58
+ tools/
55
59
  ```
56
60
 
57
61
  Minimal usage:
@@ -111,7 +115,7 @@ const harness = await createAgentHarness();
111
115
 
112
116
  #### Create A Harness From A Prebuilt WorkspaceBundle
113
117
 
114
- If your application already compiled a workspace, or you want tighter control in tests, you can pass a `WorkspaceBundle` directly instead of a filesystem path.
118
+ If your application compiles a workspace in code, or you want tighter control in tests, you can pass a `WorkspaceBundle` directly.
115
119
 
116
120
  ```ts
117
121
  import { createAgentHarness } from "@botbotgo/agent-harness";
@@ -356,7 +360,7 @@ try {
356
360
 
357
361
  ### 2. Use It Inside An App Workspace
358
362
 
359
- The example app in [`examples/stock-research-app`](/Users/boqiang.liang/900-project/agent-harness3/examples/stock-research-app/README.md) is the reference shape for an application workspace. It keeps the framework package separate from app-specific agents, tools, and skills.
363
+ The example app in [`examples/stock-research-app`](/Users/boqiang.liang/900-project/agent-harness/examples/stock-research-app/README.md) is the reference shape for an application workspace. It keeps the framework package separate from app-specific agents, tools, and skills.
360
364
 
361
365
  Run the example:
362
366
 
@@ -373,26 +377,28 @@ Agent Harness is workspace-first. The runtime is assembled from files on disk ra
373
377
  ### Core Files
374
378
 
375
379
  - `AGENTS.md`: durable instructions and operating rules loaded into agent memory where configured
376
- - `config/model.yaml`: default chat model
380
+ - `config/models.yaml`: declared models
377
381
  - `config/runtime.yaml`: workspace-wide runtime defaults such as `runRoot` and host routing
378
- - `config/direct.yaml`: lightweight direct-response host agent
379
- - `config/orchestra.yaml`: default orchestration host agent
382
+ - `config/agents/direct.yaml`: lightweight direct-response host agent
383
+ - `config/agents/orchestra.yaml`: default orchestration host agent
380
384
  - `config/embedding-model.yaml`: embeddings preset for retrieval flows
381
385
  - `config/vector-store.yaml`: vector store preset for retrieval flows
386
+ - `resources/package.json`: resource package boundary for local tools and skills
387
+ - `resources/tools/`: local code-authored tools discovered automatically
388
+ - `resources/skills/`: local skills and skill-local assets
382
389
 
383
390
  ### Minimal Model Config
384
391
 
385
392
  ```yaml
386
393
  apiVersion: agent-harness/v1alpha1
387
- kind: Model
388
- metadata:
389
- name: default
394
+ kind: Models
390
395
  spec:
391
- provider: ollama
392
- model: gpt-oss:latest
393
- init:
394
- baseUrl: http://localhost:11434
395
- temperature: 0.2
396
+ - name: default
397
+ provider: ollama
398
+ model: gpt-oss:latest
399
+ init:
400
+ baseUrl: http://localhost:11434
401
+ temperature: 0.2
396
402
  ```
397
403
 
398
404
  ### Runtime Routing
@@ -404,7 +410,7 @@ spec:
404
410
 
405
411
  ### Agent Config
406
412
 
407
- Agent objects are declarative YAML files. The package currently supports:
413
+ Agent objects are declarative YAML files. The package supports:
408
414
 
409
415
  - `LangChainAgent`
410
416
  - `DeepAgent`
@@ -415,6 +421,8 @@ Typical fields include:
415
421
  - `metadata.description`
416
422
  - `spec.modelRef`
417
423
  - `spec.systemPrompt`
424
+ - `spec.tools`
425
+ - `spec.mcpServers`
418
426
  - `spec.checkpointer`
419
427
  - `spec.memory`
420
428
  - `spec.store`
@@ -422,19 +430,79 @@ Typical fields include:
422
430
 
423
431
  Use `LangChainAgent` for a fast direct path. Use `DeepAgent` when you need richer orchestration, tool-heavy execution, memory backends, and delegation.
424
432
 
433
+ ### Local Tool Authoring
434
+
435
+ Local tools live under `resources/tools/` and are discovered automatically from `.js`, `.mjs`, and `.cjs` modules.
436
+
437
+ `resources/package.json` is not only metadata. It defines the dependency boundary for local tools and skill-local scripts. Tool modules are loaded with `resources/` as their package root, so dependencies should be declared under `resources/package.json` rather than relying on the app root package.
438
+
439
+ Recommended authoring style:
440
+
441
+ ```js
442
+ import { z } from "zod";
443
+ import { tool } from "@botbotgo/agent-harness/tools";
444
+
445
+ export const stock_lookup = tool({
446
+ description: "Lookup a ticker.",
447
+ schema: {
448
+ ticker: z.string().min(1),
449
+ },
450
+ async invoke(input) {
451
+ return input.ticker.toUpperCase();
452
+ },
453
+ });
454
+ ```
455
+
456
+ Then reference the tool from the agent:
457
+
458
+ ```yaml
459
+ spec:
460
+ tools:
461
+ - tool/stock_lookup
462
+ ```
463
+
464
+ ### MCP Servers On Agents
465
+
466
+ MCP servers are configured directly on the agent. The framework connects to each server, lists its remote tools, and automatically exposes the selected ones on that agent.
467
+
468
+ ```yaml
469
+ spec:
470
+ modelRef: model/default
471
+ mcpServers:
472
+ - name: chrome-devtools
473
+ command: npx
474
+ args:
475
+ - chrome-devtools-mcp@latest
476
+ toolFilter:
477
+ - ^page_
478
+ - ^network_
479
+ excludeToolFilter:
480
+ - _deprecated$
481
+ ```
482
+
483
+ Supported MCP fields:
484
+
485
+ - `name`
486
+ - `command`, `args`, `env`, `cwd`
487
+ - `transport`, `url`, `token`, `headers`
488
+ - `tools`
489
+ - `excludeTools`
490
+ - `toolFilter` or `toolFilters`
491
+ - `excludeToolFilter` or `excludeToolFilters`
492
+
425
493
  ## How To Extend
426
494
 
427
495
  The extension model is filesystem-based. You extend the harness by adding new config objects, new discovery roots, or new resource packages.
428
496
 
429
497
  ### Add More Agents
430
498
 
431
- Subagents can be discovered from configured roots. The discovery layer supports:
499
+ Agents live under config roots such as `config/agents/`. The discovery layer supports:
432
500
 
433
501
  - local filesystem paths
434
502
  - external resource sources
435
503
  - builtin discovery paths
436
504
 
437
- The harness scans YAML files under the discovered agent roots and adds them to the workspace graph.
505
+ The harness scans YAML files under the discovered agent roots and adds them to the workspace graph. `resources/` is for executable assets such as tools and skills, not agent YAML.
438
506
 
439
507
  ### Add Skills
440
508
 
@@ -443,6 +511,30 @@ Skills are discovered from roots that contain either:
443
511
  - a direct `SKILL.md`
444
512
  - child directories where each directory contains its own `SKILL.md`
445
513
 
514
+ `SKILL.md` should use YAML frontmatter. The harness reads `name` and the standard `stack` field from frontmatter, then exposes that metadata through runtime inventory helpers such as `listAgentSkills(...)` and `builtin.list_available_skills`.
515
+
516
+ Example:
517
+
518
+ ```md
519
+ ---
520
+ name: code-review
521
+ description: Review code changes for correctness and regression risk.
522
+ stack:
523
+ - typescript
524
+ - vitest
525
+ ---
526
+
527
+ # Code Review
528
+
529
+ Use this skill when the user wants a correctness-focused review of a patch.
530
+ ```
531
+
532
+ Notes:
533
+
534
+ - `name` should be stable and unique within the discovered skill set
535
+ - `stack` should be a list of technologies, frameworks, or platforms the skill is designed for
536
+ - if `stack` is omitted, the runtime treats it as an empty list
537
+
446
538
  A practical layout looks like this:
447
539
 
448
540
  ```text
@@ -459,12 +551,18 @@ your-workspace/
459
551
 
460
552
  Tools can come from:
461
553
 
462
- - resource packages
554
+ - local modules under `resources/tools/`
463
555
  - external sources
464
556
  - builtin resources
465
- - declarative tool objects that bundle or reference other tools
557
+ - MCP servers declared on an agent under `spec.mcpServers`
558
+
559
+ The example application demonstrates the local pattern: keep app-specific tools under `resources/tools/` and keep one tool per module.
560
+
561
+ Dependency rule:
466
562
 
467
- The example application demonstrates a clean pattern: keep app-specific tools under `resources/tools/` and keep one tool per module.
563
+ - declare tool runtime dependencies in `resources/package.json`
564
+ - do not rely on the app root `package.json` for modules imported by files under `resources/tools/`
565
+ - keep reusable helper modules for tools under `resources/` so they stay inside the same package boundary
468
566
 
469
567
  ### Add Retrieval
470
568
 
@@ -486,19 +584,34 @@ The public API also accepts a prebuilt `WorkspaceBundle`, which lets you compile
486
584
  your-workspace/
487
585
  AGENTS.md
488
586
  config/
489
- model.yaml
587
+ models.yaml
490
588
  runtime.yaml
491
- direct.yaml
492
- orchestra.yaml
589
+ agents/
590
+ direct.yaml
591
+ orchestra.yaml
493
592
  embedding-model.yaml
494
593
  vector-store.yaml
495
594
  resources/
496
- agents/
595
+ package.json
497
596
  skills/
498
597
  tools/
499
598
  .agent/
500
599
  ```
501
600
 
601
+ ## Release Flow
602
+
603
+ Publishing is automated from `master`.
604
+
605
+ When a commit lands on `master`, the GitHub `Release` workflow:
606
+
607
+ 1. runs `npm ci`, `npm run build`, `npm run check`, and `npm test`
608
+ 2. bumps the package with `npm version patch --no-git-tag-version`
609
+ 3. syncs `examples/stock-research-app/package.json` to the new package version
610
+ 4. commits the version change back to `master` and creates a matching `v*` tag
611
+ 5. verifies the tarball and publishes to npm
612
+
613
+ That means normal feature and fix commits should not manually edit the package version. Version bumps are owned by the release workflow.
614
+
502
615
  ## Development
503
616
 
504
617
  Build and test this package locally:
@@ -509,4 +622,4 @@ npm run check
509
622
  npm test
510
623
  ```
511
624
 
512
- The example workspace under [`examples/stock-research-app`](/Users/boqiang.liang/900-project/agent-harness3/examples/stock-research-app/README.md) is the fastest way to understand how an app should package its own agents, tools, and skills around this framework.
625
+ The example workspace under [`examples/stock-research-app`](/Users/boqiang.liang/900-project/agent-harness/examples/stock-research-app/README.md) is the fastest way to understand how an app should package its own agents, tools, and skills around this framework.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@botbotgo/agent-harness",
3
- "version": "0.0.17",
3
+ "version": "0.0.18",
4
4
  "description": "Agent Harness framework package",
5
5
  "type": "module",
6
6
  "packageManager": "npm@10.9.2",