---
title: 使用 Agent 开发 Lenso
description: 安装 Lenso 的六个开发 Skill，把工作路由到正确所有者，并驱动 Coding Agent 从源码检查走到可观察交付。
---

当你准备让 Coding Agent 构建或修改 Lenso 时，应从这里开始。六个 Lenso Skill
为产品规划、Capability Contract、Plugin 行为、App 配置与 Host 机制提供有顺序的
工作流。它们不会替代仓库源码、`--help`、测试和人工审查；它们负责告诉 Agent
应该检查什么，以及什么状态才算真正完成。

完成本指南后，你可以向 Agent 提交一个具体请求，让它选择正确的所有者工作流，
并要求它返回可检查的实现与交付报告。

## 1. 安装 Skill Pack

先检查公开 Catalog：

```sh
npx skills add LioRael/lenso --list
```

为安装器检测到的项目 Agent 安装全部六个 Skill：

```sh
npx skills add LioRael/lenso --all
```

以用户级方式安装到 Codex：

```sh
npx skills add LioRael/lenso \
  --skill '*' \
  --agent codex \
  --global \
  --yes
```

规范来源是 [Lenso Skill Pack](https://github.com/LioRael/lenso/tree/main/skills)。
安装副本是派生制品，之后可通过 `npx skills update` 刷新。

当 Agent 能看到以下准确名称时，安装才算完成：

```text
lenso-start
lenso-business-planning
lenso-capability-authoring
lenso-plugin-authoring
lenso-app-configuration
lenso-runtime-extension
```

如果出现的是 `lenso-app-composition`，而不是 `lenso-app-configuration`，说明安装的
Skill Pack 已经过期。先完成更新，再让 Agent 修改 App。

## 2. 从一个有边界的请求开始

向 Agent 提供四类输入：

| 输入 | 应该说明什么 | 为什么重要 |
| --- | --- | --- |
| 结果 | 完成后人或另一个 Plugin 可以做什么 | 避免只输出架构描述 |
| 权威来源 | 已知的仓库、Package、Host 与现有 Contract | 让源码选择保持显式 |
| 约束 | 语言、Target、兼容性、安全和允许的交付动作 | 防止扩大范围 |
| 完成条件 | 行为、真实失败、移除、检查与交付状态 | 防止过早结束 |

复制以下模板并替换方括号：

```text
使用 $lenso-start 路由并完成这个 Lenso 任务。

结果：[一个用户或 Plugin 可观察的结果]
权威来源：[仓库、Package、Host、Capability，未知时明确写未知]
约束：[语言、Target、兼容性、安全与交付范围]
完成条件：
- [必须实际运行的成功行为]
- [必须保持可区分的真实失败]
- [适用时的配置、生命周期或移除证据]
- [要求的检查以及 Commit/PR/Merge 状态]

编辑前先报告所选主工作流、所有者仓库、当前源码 API，以及任何缺失前置条件。
除非缺失条件会实质改变请求的产品结果，否则报告后继续完成任务。
```

最后一段提供了早期审查点，同时不会让 Agent 因普通实现选择而停下来等待。

## 3. 让 `lenso-start` 路由工作

当前所有权问题只选择一个主工作流：

| 请求结果 | 主 Skill | 完成边界 |
| --- | --- | --- |
| 把模糊结果变成纵向产品行为 | `lenso-business-planning` | Plugin Card、显式 Capability Edge 与一个 Tracer Slice |
| 定义或演进跨 Plugin 角色 | `lenso-capability-authoring` | Descriptor、Schema、生成 Binding、兼容性与 Freshness 证据 |
| 实现可移除行为 | `lenso-plugin-authoring` | Plugin Contract、受支持实现、真实 Consumer Path 与移除证据 |
| 在一个 App 中配置 Package 与 Instance | `lenso-app-configuration` | 已审查的 `plugins/` 差异、Derived App、行为与移除证据 |
| 添加调度、进程、传输、Endpoint 或 Host 机制 | `lenso-runtime-extension` | 狭窄的 Driver、Adapter、Runner 或 Generation 改动及 Conformance、Host 证据 |
| 判断上述哪一行持有请求 | `lenso-start` | 一个主工作流与一个可检查完成状态 |

一个 Feature 可以跨越多行。Agent 应先完成一个所有者边界，再交给下一个工作流。
例如，一个新 Web API 可能需要业务 Plugin、HTTP Endpoint Provider 与 App 配置；
这不意味着三者必须放进同一个 Package。

Kernel 语义不是常规的第七工作流。图校验、生命周期、准入、调用、Readiness、监督
或诊断变更，需要对应 Architecture Decision 与 Portable Conformance 证据。

## 4. 实现前必须检查源码

Agent 应按以下顺序检查：

1. 仓库说明与 Dirty Worktree；
2. Package Manifest、Lock 与确定的依赖版本；
3. Capability Source 和生成的 Provider/Client Projection；
4. 现有 Plugin Descriptor、Factory、Entrypoint 与 Host Registration；
5. App 的 Host Catalog 与可见 `plugins/` 差异；
6. 能证明受影响路径的仓库 CI 或本地命令。

只有方案中的每个 API 和命令都来自当前源码或已安装的 `--help`，这一步才算完成。
ADR 可以解释意图，但不能证明 Package、命令、Scaffold 或远程服务已经交付。

第一次编辑前要求一份简短 Routing Report：

```text
现在返回 Routing Report：
- 主 Skill；
- 所有者与删除边界；
- 当前源码文件与 Package 版本；
- 提供和依赖的 Capability；
- App/Host 改动；
- 第一个成功、真实失败与移除证据；
- 未支持或缺失的前置条件。
```

## 5. 为实际任务选择 Prompt

### 增加一个 Plugin 行为

```text
使用 $lenso-plugin-authoring，以 Rust 添加 company.uppercase，作为一个可移除的
Agent Tool Plugin。

使用当前 CLI Scaffold 和已安装的 --help。所有打包实现必须共享一个 Plugin
Contract。实际运行成功的大写转换与无效参数，打包受支持实现，把 Bundle 安装到
维护中的 Agent Host，通过真实 Agent Turn 调用它，然后移除并重新解析 App。
报告准确路径与命令。
```

对应的人工教程见[为 Agent 添加一个 Tool](/docs/zh/agent/first-app)。

### 配置已有 App

```text
使用 $lenso-app-configuration，只修改这个 App 可见的 plugins/ 差异。

结果：review Profile 使用 semantic Session presentation Instance。先检查准确的
Host Catalog 与当前 Derived App。添加最小 Instance TOML 与 Profile Selection，
Secret 值保持外部化，运行 app show 与 app check，实际启动一个新 Session，然后
移除该差异，证明 Host Default 再次可见。
```

文件和发布模型见[配置 Plugin](/docs/zh/core/plugin-configuration)与
[配置 Agent](/docs/zh/agent/agent-configuration)。

### 构建 Web 后端

```text
使用 $lenso-start，然后使用选中的 Plugin 与 App 工作流，添加一个 JSON Web 后端：
POST /greetings 与 GET /greetings/{greeting_id}。

使用当前 lenso.http.endpoint@1 Authoring API，以及现有 Host 已链接的 Web Ingress。
Route 形态留在 HTTP Endpoint Provider，Transport Limit 留在 Ingress 配置；在 Handler
运行前拒绝无效 JSON；通过真实 Socket 证明 201、200、400、404 与 405；并证明
Route Collision 会阻止 Readiness。如果已安装 CLI 没有 Web Scaffold，不要发明一个。
```

完整人工步骤与当前兼容边界见[开发 Web 后端](/docs/zh/web)。

### 增加 Host 机制

```text
使用 $lenso-runtime-extension 添加缺失的 Host 机制。

说明为什么现有 Driver、Execution Adapter、Runner 或 Plugin 都不能持有该结果。
除非不变量本身是 Portable 的，否则保持 Kernel 不变。增加 Conformance、真实 Host
Boundary 证据、Cancellation 与 Shutdown 行为，并报告哪些产品 Plugin 现在可以使用
这个机制。
```

## 6. 控制 Agent 可以交付到哪里

明确允许的交付级别：

| 级别 | Agent 在哪里停止 |
| --- | --- |
| 调查 | 基于源码的结论与建议所有者边界；不修改产品文件 |
| 实现 | Working Tree 改动与相称检查；不 Commit，不外部发布 |
| 交付 | 请求的 Commit、PR、Required Checks、Merge 验证与安全清理 |

“Review”或“Explain”不授权创建 PR。“Implement”不意味着发布 Package。要求交付时，
明确仓库以及是否必须在 Merge 前停止。

## 7. 审查所有权边界，而不是活动日志

### 路由完成后

- 主 Skill，以及它为什么持有下一个决定；
- 所有者仓库与删除边界；
- 准确的当前 API、命令与 Package 证据；
- 会改变请求结果的缺失前置条件。

### 实现完成后

- 修改的制品路径与生成文件 Freshness；
- 成功、Domain Error、Runtime/Startup Failure 与 Lifecycle 证据；
- 真实 Consumer-to-Provider 或 Host Boundary 执行；
- 配置与 Resolved Plan 的影响；
- 可选行为的移除证据。

### 交付完成后

- Commit 与远程 Branch；
- PR 与 Required Checks；
- Merge Commit 或远程 Tree 证据；
- 有意保留、未被清理的 Dirty 或 Unmerged 工作。

架构词汇、文件数量，以及不含准确命令的“测试已通过”，都不是完成证据。

## 8. Agent 方向错误时如何纠正

使用聚焦纠正，不必重新开始整个任务：

```text
暂停实现并重新运行 $lenso-start。

当前方向似乎把 [行为] 放进了 [错误所有者]。重新检查 Plugin 删除边界、Capability
Source、Host Catalog 与现有 Adapter。继续前先返回纠正后的主工作流与最小可逆切片。
```

常见纠正方式：

| 症状 | 纠正方式 |
| --- | --- |
| Agent 为普通产品行为提出 Kernel 改动 | 路由到 Plugin Authoring |
| Agent 手写 Binding | 路由到 Capability Authoring 并重新生成 |
| Agent 在 App 文件中选择实现 | 保持 Host Policy 权威；App Configuration 只持有可见差异 |
| Agent 把检查本身当成功能 | 重申可观察结果，把检查保留为完成证据 |
| Agent 声称存在未交付的远程服务或 Scaffold | 要求 Package Source、已安装 `--help` 或可执行 Owner Example |

当 Agent 能识别正确所有者、完成最小的源码支撑改动、通过真实 Consumer 运行结果，
并返回足够信息让另一个开发者重跑或审查时，这条工作流才算成功。