실제 제품을 적절한 조작 환경에서 실행해 변경 사항을 검증하고, 사용자가 확인할 수 있는 증거를 모아 인수 보고서로 게시합니다. 기존 검증 계획을 확인하거나 점검 항목을 만들고, `lh` CLI로 결과를 게시할 수 있습니다.
- 변경된 제품 동작을 실제로 확인하기
- 스크린샷 등 검증 증거 수집하기
- 검증 계획과 보고서 작성하기
LobeHub의 내장 에이전트 도구를 새로 만들거나 확장할 때 참고하는 가이드입니다. 매니페스트와 타입, 런타임 처리, 프런트엔드 실행기, 채팅 화면, 등록 설정을 다루며 각 부분을 일관되게 연결하는 규칙을 설명합니다.
Use for LobeHub builtin agent tools: manifests, executors, runtimes, inspectors, renders, streaming and intervention.
실행 점수 미검증
설치 방법 보기LobeHub의 내장 에이전트 도구를 만들거나 확장하는 방법을 안내합니다. 매니페스트와 타입 정의, 런타임 처리, 프런트엔드 실행기, 채팅 화면, 중앙 레지스트리 등록을 다룹니다. Inspector는 각 API를 표시하는 데 사용하며, 결과 카드와 실행 중 표시, 승인 화면은 필요한 경우에 추가합니다. 식별자와 결과 필드, 번역 키, API 정의와 화면의 대응 관계처럼 구현에서 일관되게 맞춰야 할 항목도 확인할 수 있습니다.
새 내장 도구 패키지를 만들거나 기존 도구에 API를 추가할 때 참고할 수 있습니다. Inspector, Render 등의 도구 화면을 만들 때와 도구를 찾을 수 없거나 결과가 표시되지 않는 등록·표시 문제를 조사할 때도 유용합니다.
자료에는 @lobehub/ui, createStaticStyles 등의 지정 라이브러리와 스타일 규칙이 나옵니다. 자세한 설계 자료는 스킬의 references/ 디렉터리에 있습니다.
이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.
AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.
점수에는 넣지 않았습니다. 2026년 10월 26일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
A builtin tool is a package the agent runtime can call. It ships five faces:
| Face | Lives in | Audience |
|---|---|---|
| Manifest + types | src/{manifest,types,systemRole}.ts | The LLM (tool spec + system prompt) |
| ExecutionRuntime | src/ExecutionRuntime/ | Server / desktop / any runtime caller |
| Executor | src/client/executor/ | Frontend (wraps stores/services) |
| Client UI | src/client/{Inspector,Render,…}/ | Chat UI |
| Registry wiring | packages/builtin-tools/src/*.ts + src/store/tool/slices/builtin/executors/index.ts | Framework |
| Question | Doc |
|---|---|
| Where do files live? What does each face do? Wiring? | architecture.md |
| How do I name the tool, design APIs, write the manifest, executor, ExecutionRuntime? | tool-design.md |
| How do I build Inspector / Render / Placeholder / Streaming / Intervention / Portal? | ui/ |
packages/builtin-tool-<name>/ packagelobe-<domain> identifier is permanent. It's stored in message history. Renames need legacy aliases kept alongside the new name (see the // Legacy aliases entries in packages/builtin-tool-local-system/src/client/Inspector/index.ts, kept after listLocalFiles/searchLocalFiles were renamed to listFiles/searchFiles). Get it right the first time.as const object, not a TS enum. It doubles as the runtime list BaseExecutor iterates over.content: string → the LLM reads itstate: Record<…> → the UI's pluginState; result-domain only, never echo all params backerror: { type, message, body? } → both LLM and UI; type is a stable codesrc/ExecutionRuntime/ — pure runtime, no React, no Zustand, accepts services via constructor. The default place for new logic.src/client/executor/ — BaseExecutor subclass that calls ExecutionRuntime (or stores/services directly when frontend-only).createStaticStyles + cssVar.* (zero-runtime). Fall back to createStyles + token only when you genuinely need runtime values. Use @lobehub/ui components, not raw antd.packages/locales/src/default/plugin.ts. Inspector titles must come from t('builtins.<identifier>.apiName.<api>') so something renders while args stream.callSubAgent stops halfway, the user says "keep going". So the fix was an optional subAgentId on callSubAgent that appends a new instruction to the same sub-agent thread — not a new "look up that run" API the model has to remember to call before retrying from scratch. Add a new API only when a user would ask for it on its own.packages/builtin-tool-<name>/
├── package.json
└── src/
├── index.ts # exports manifest + types + systemRole + Identifier (no React, no stores)
├── manifest.ts # BuiltinToolManifest with JSON Schema for every API
├── types.ts # ApiName const + Params/State interfaces per API
├── systemRole.ts # System prompt teaching the model when/how to use the APIs
├── ExecutionRuntime/ # ✅ Default home for runtime logic (server- or anywhere-callable)
│ └── index.ts
└── client/
├── index.ts # Re-exports for the registries
├── executor/ # ✅ Frontend executor — extends BaseExecutor, often delegates to ExecutionRuntime
│ └── index.ts
├── Inspector/ # required — header chip per API
├── Render/ # optional — rich result card
├── Placeholder/ # optional — skeleton during streaming/execution
├── Streaming/ # optional — live output renderer (e.g. RunCommand, WriteFile)
├── Intervention/ # optional — approval / edit-before-run UI
├── Portal/ # optional — full-screen detail view
└── components/ # shared subcomponents used by the surfaces above
Older packages (builtin-tool-calculator, etc.) still have src/executor/ as a sibling of src/client/. That's grandfathered; don't relocate without a deliberate refactor. New packages and new APIs added to existing packages should follow the layout above.
package.json exports map:
"exports": {
".": "./src/index.ts",
"./client": "./src/client/index.ts",
"./executor": "./src/client/executor/index.ts",
"./executionRuntime": "./src/ExecutionRuntime/index.ts"
}
Before opening the PR:
lobe-<domain> and is stable (lives in message history).<Name>ApiName value has: a manifest api[] entry, an executor method, an Inspector, an i18n apiName.* key.Params interfaces match the JSON Schema; State interfaces match what the executor returns and what the UI surfaces read.ExecutionRuntime/; the client/executor/ only wires stores/services and delegates.{ success, content, state, error? } via a single toResult() funnel — content always non-empty (default to error.message).isArgumentsStreaming, isLoading, partialArgs, missing pluginState.null until it has data; only created for APIs with rich results.humanIntervention is set in the manifest.packages/locales/src/default/plugin.ts plus dev seeds in en-US/zh-CN.bunx vitest run --silent='passed-only' 'packages/builtin-tool-<name>' passes.bun run type-check passes.Pick the closest neighbor and copy:
| If your tool is… | Read first |
|---|---|
| Pure-compute, no UI state | packages/builtin-tool-calculator/ — ExecutionRuntime reuses executor (mathjs/nerdamer work everywhere) |
| CRUD over a domain entity | packages/builtin-tool-task/ — full Inspector + Render set, batch variants |
| Heavy UI (Inspector/Render/Placeholder/Portal) | packages/builtin-tool-web-browsing/ — search-style result UI, Portal for detail view |
| Desktop / filesystem with all surfaces (incl. Streaming + Intervention) | packages/builtin-tool-local-system/ — ExecutionRuntime injects an ILocalSystemService, executor calls it |
| Server-side pure (no client executor) | packages/builtin-tool-web-browsing/ — only ExecutionRuntime is exported; the chat client doesn't run it |
| Needs human approval before running | packages/builtin-tool-local-system/src/client/Intervention/ — per-API approval components |
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
실제 제품을 적절한 조작 환경에서 실행해 변경 사항을 검증하고, 사용자가 확인할 수 있는 증거를 모아 인수 보고서로 게시합니다. 기존 검증 계획을 확인하거나 점검 항목을 만들고, `lh` CLI로 결과를 게시할 수 있습니다.
LobeHub에 AI 모델 제공자를 추가하는 과정을 안내합니다. 런타임 연동, 모델 정보와 설정, 브랜드 표시, 문서화 및 인수 확인을 다루며, 기존 제공자에 모델만 추가하는 경우와 새 연동이 필요한 경우를 구분합니다.
서버 환경 변수로 사용자 설정의 기본값을 지정하도록 구현하는 절차를 안내합니다. 변수 검증, 서버 설정 구성, 사용자 저장소 반영부터 예시 환경 파일과 셀프 호스팅 문서 갱신까지 다룹니다.
에이전트 실행 단계, 도구 호출, 사람의 승인, 컨텍스트 압축, 하위 에이전트 호출에 훅을 등록하는 방법을 안내합니다. 이벤트를 관찰하고 로컬 도구 결과를 모의하거나 설정에 따라 웹훅으로 도구 호출을 허용 또는 거부할 수 있습니다.
에이전트의 이벤트 기반 백그라운드 작업을 설계하고 구현하도록 돕습니다. 소스, 시그널, 액션, 정책의 역할을 나누고 비동기 처리, 중복 실행 방지, 완료 기록과 관측 기능을 다룹니다.
실제 데스크톱 채팅 앱에서 봇 채널의 인수 테스트를 진행합니다. Discord, Slack, Telegram, WeChat, Lark, QQ에서 메시지를 보내고 응답을 기다린 뒤 결과 화면을 캡처합니다. iMessage는 BlueBubbles 브리지를 사용합니다.