lark-harness: Lark Harness: The Agent Runtime That Turns Feishu Into a Governed Operating System
A Bash-based runtime uses Lark Base, Messenger, and Approvals to give AI agents memory, workflow, and guardrails without building a separate platform.
支援の核になっているのが、私たちが自社開発したLARC（Lark Agent Runtime）というフレームワークです。 LARCは、AIが業務タスクを実行するときに、「このタスクに必要な権限はこれだけ」「この操作は人間の承認が必要」「このAIはこれができる」といったルールを自動で管理する仕組みです。 GitHubでオープンソースとして公開しており、実際のLark（飛書）環境で動作を検証済みです。
- LARK is the runtime, not just the chat window, because it turns messenger, base, and approvals into the control plane for agent work.
- The project’s real invention is permission-first orchestration, where risky actions are routed through policy checks and native human approval.
- Bash is not a compromise here, because it keeps the dispatcher thin while pushing heavier work into focused helpers and external CLIs.
- The repo treats documentation as machine-readable context, so skills become part of the runtime instead of separate reference material.
Most agent projects start by asking how much power they can give a model. Lark Harness asks the better question: how little power can you give it and still make it useful? That shift is the whole story.
Lark Is the Product
The surprise in Lark Harness is not that it connects to Lark. It treats Lark as the operating environment itself. Messenger becomes the operator surface, Lark Base becomes durable state, and Approvals become the safety valve.
That makes the repo feel less like a bot integration and more like a permission-first office OS. The agent is not wandering across SaaS tools on its own. It is moving through a place that already has memory, policy, and a human override path.
Why Permission Comes First
The quote lands because it describes the core design in plain language. LARC is not trying to make agents omnipotent. It is trying to make them legible.
The Runtime Is a State Machine
Under the hood, the lifecycle is simple and strong: enqueue, run-once, done, or fail. That looks boring until you realize what it buys. The agent is not chatting endlessly. It is claiming work, acting once, and writing the result back into Lark Base as an audit trail.
{
"task": "create_expense",
"state": "enqueue",
"claimed_by": null,
"policy": {
"risk": "high",
"gate": "approval"
}
}That is closer to asynchronous job orchestration than to prompt-and-tools chat. The runtime can retry, log, and hand off without losing the thread. Lark Base is doing the quiet, important job of persistence.
Bot or User? The Auth Router Decides
| Case | Identity | Why it matters |
|---|---|---|
| Base reads and notifications | Bot | Cheap, safe, and usually sufficient for ambient automation. |
| Calendar and approval-sensitive work | User | Some SaaS actions require a real user context to succeed. |
| External direct messages | Blocked | The router avoids known failure paths and bad API outcomes. |
| Sensitive workflow actions | Policy-driven | The runtime chooses identity based on the task, not on habit. |
The interesting part of auth.sh is not authentication in the abstract. It is the decision logic around identity. In SaaS automation, the wrong identity is often worse than no automation at all.
LARC makes that choice explicit. Sometimes the bot is enough. Sometimes the user has to stand behind the action. Sometimes the safest answer is to stop.
Bash Is the Glue, Not the Limitation
Bash here is a strategic choice. It gives the repo portability, lazy loading, and a very small surface area for the dispatcher. Heavier lifting can move into Python or the Lark CLI without bloating the entry point.
| Layer | What it does | Why it fits |
|---|---|---|
| Bash dispatcher | Subcommand routing and environment setup | Portable and easy to inspect |
| Python helpers | Data shaping and scenario logic | Better for complex transforms |
| Lark CLI | Platform integration | Uses the official surface instead of reimplementing it |
Skills as Documentation for Machines
The .claude/skills tree is one of the smartest parts of the repo. It is not just human documentation. It is runtime context for an LLM-based agent. That means the project ships its domain knowledge in a form the model can actually consume when it needs it.
That is a subtle but real shift. Documentation stops being passive reference material and becomes part of the execution environment. The repo is teaching the agent while the agent is working.
.claude/skills/
larc-runtime/
approvals/
base/
messenger/For office automation, that matters. If the agent needs to know how a Lark-specific operation behaves, the answer should be local, structured, and close to the command path. This repo leans into that.
Where LARC Fits Among Agent Runtimes
| Project | Primary focus | What LARC does differently |
|---|---|---|
| LARC | Governed office workflows inside Lark | Turns the platform into the runtime and adds approval gates |
| E2B | Secure sandbox execution | Focuses on isolated code environments rather than SaaS governance |
| LangGraph | Stateful agent orchestration | Orchestrates flows, but does not ship a Lark-native control plane |
| nanobot | Multi-channel lightweight agent | Connects to Lark, but does not center policy and auditability |
| cc-connect | Bridge between coding agents and chat | Moves messages between systems instead of making Lark the execution layer |
That comparison is the point. LARC does not try to win the whole agent market. It carves out a narrower, more credible niche: enterprise office work inside a specific collaboration stack, with policy, persistence, and approvals built in.
