---
title: Agent 开发
description: 使用 Lenso Skill、Scaffold、Check 与 Lenso Console 状态，和 Coding Agent 协作开发。
---

Lenso 通过公开 Skill、明确 Manifest、生成合约、Owner-local Check 与配置的
Console Service URL，为 Coding Agent 提供受约束工作流，不需要自定义 Agent
Runtime。

当人类或编码 Agent将产品创意转变为产品时，请使用此路径
主机、链接模块、服务支持的模块或 API 集成。

## 安装技能

在要求代理构建主机之前安装公共Lenso技能包或
模块：

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

如果您在本地结账处工作，相同的技能文件位于
Lenso 存储库中的 `skills/`。复制或注册这些技能目录
您的代理配置的技能文件夹，然后从 `lenso-start` 开始。

## 公共技能路径

|目标|技能|第一个命令或来源 |
| --- | --- | --- |
|澄清模糊的商业想法| `lenso-business-planning` |选择第一个有用的切片 |
|选择正确的公共路径 | `lenso-start` |路由到主机、链接模块、服务支持模块或 API 客户端 |
|组合或演进生成的业务应用 | `lenso-app-composition` |检查当前的 `lenso app --help` |
|创建可重用的能力包 | `lenso-app-composition` |检查当前的 `lenso capability --help` |
|创建 Host 应用脚手架 | `lenso-starter-host` | `lenso host init <dir>` |
|构建 Rust 模块 | `lenso-module-authoring` | `lenso module create <name>` |
|构建进程外服务模块 | `lenso-service-authoring` | `lenso service create <name> --lang ts` |
|构建或改进 Console Surface | `lenso-console-surface-authoring` |检查当前 Console Module 包和所属 Module 声明 |
|使用 Lenso API | `lenso-api-client` | `contracts/openapi/app-api.v1.yaml` |
|构建独立权威 Service | `lenso-autonomous-service-authoring` |先验证当前 GA Support Manifest |
|演进 Contract | `lenso-contract-evolution` |盘点生产者、消费者和已提交制品 |
|设计 Durable Workflow | `lenso-durable-workflow` |定义不可变版本和稳定标识 |
|提取 Linked Module | `lenso-module-extraction` |运行当前 Extraction Check |
|诊断事故 | `lenso-incident-recovery` |恢复前收集精确诊断记录 |
|准备或恢复发布 | `lenso-reviewed-release` |读取所属仓库的发布流程 |

公共技能包位于Lenso存储库的`skills/`目录中。

## Agent 循环

1. 从可检查的最小业务切片开始。
2. 选择 Host、Linked Module、Service-backed Module 或 API Client 工作。
3. 使用 CLI Scaffold，不手工构建形态。
4. 实现一项有用能力。
5. 添加一项可运行 Check；能力未接入时，它必须失败。
6. 打开配置的 Console Service URL，确认 Module 状态可见。
7. 报告命令、Check 结果与 Lenso Console 状态。

公开产品切片从这个 Prompt 开始：

```text
Build a support ticket module for a Lenso app.
```

预计路由是：

```text
lenso-start -> lenso-business-planning -> lenso-app-composition -> 实现 skill -> checks -> Console Service 根地址
```

对于可重用切片，通过能力包进行路由：

```text
lenso capability init -> lenso capability library add -> lenso capability fit -> lenso app compose --pack -> lenso agent task --for-capability -> checks -> Console Service 根地址
```

## Prompt 结构

为代理提供具体的模块结果，而不是通用的框架任务：

```text
Build a support ticket module for a Lenso app.

First slice:
- tickets have title, status, priority, requester email, and assignee
- operators can list tickets and assign one
- escalation is a runtime function
- the module is visible in Console Service 根地址
- leave one smoke check
```

这为代理提供了足够的边界，以避免发明平台。

## 按路径检查

|路径|最低有用检查 |
| --- | --- |
|主机首发| `cargo check --bins` |
| Capability Pack | `lenso capability fit <pack> --repo-root .` 加上生成的 App Composition |
| Rust Module | Manifest 或 Smoke Check，以及配置的 Console Service 状态 |
| Service-backed Module | 所属 Service Contract Check 与已组合应用 Binding |
|合约/API 工作 |所属仓库的生成与新鲜度检查 |
|架构敏感的后端工作 |所属仓库的架构检查 |

检查应该是小型的、局部的，并且与能力相关。只编译
当更改应该出现在Lenso Console中时，通过是不够的。

## Console 状态

使用配置的 Console Service URL 确认已连接 System 看到了这项工作：

- **Modules** 显示 Module、Manifest 与精确回执绑定的 Surface 状态。
- **Services** 显示 Provider、Workload 与 Adapter Connection 细节。
- **Stories** 显示由精确 Story Module 贡献的相关记录。
- Workload Operational State 与 Connection State 保持独立。

## 不要越过这些边界

- 在所有权边界确定之前，不要将模糊的想法拆分为微服务
  真实的。
- 在真正的模块需要它之前，不要构建通用的 CRUD 框架。
- 不要交叉导入另一个模块的内部结构。
- 当公共 CLI、crate、npm 时，不需要克隆框架 monorepo
  包装或技能适合。
- 不要把 Agent-ready 当作自主部署承诺。Agent 仍需留下 Check 与运维人员可见
  的状态。