Vendors are aggressively hyping up the release of platform CLIs (Feishu, DingTalk) as a massive breakthrough for the Agent execution layer. The premise is absurdly naive: point an LLM at a command-line interface, and watch enterprise automation solve itself.

To any architect who builds systems that actually survive production, this is garbage. Exposing a native CLI executable to an LLM is a single-player toy masquerading as B2B infrastructure. It is a ticking time bomb for state corruption and data breaches.

1. Token Incineration and Cascading State Corruption

Relying on an LLM to dynamically parse CLI schemas and execute tools via ReAct loops is an inexcusable waste of compute. You are burning tokens to let a model guess parameter structures on the fly.

When you give an LLM the unbounded freedom of a generalized CLI, syntax hallucinations are inevitable. A missed flag or malformed query instantly triggers a 400 Bad Request death spiral. Worse, if the hallucination produces a valid but incorrect command, corrupted state is written back into your business databases. This triggers cascading failures across your entire automation pipeline.

Production environments require absolute determinism. Workflows must be locked down by hardcoded DAGs via LangGraph or strict standard operating procedures. The LLM belongs strictly inside isolated compute nodes for unstructured data transformation. It must never be granted sovereign control over the execution runtime.

2. The Multi-Tenant Race Condition

The fundamental flaw of official CLI tools is their single-player DNA. Executables like lark-cli rely on global configuration files (~/.config) or static environment variables for authentication.

Deploy this toy in a 50-person enterprise Slack channel. When Employee A and Employee B concurrently ask the Agent to fetch confidential project data, how does the underlying process isolate their credentials?

If your Agent defaults to a global Admin Token, your permission boundaries collapse instantly, causing a massive cross-tenant data breach. If you attempt to dynamically overwrite global environment variables during concurrent requests, you immediately introduce race conditions and multi-threading state pollution. Any Agent infrastructure lacking dynamic, request-scoped authentication isolation is fundamentally broken.

3. The Production Standard: Native Tools and Identity Gateways

At Limina Labs, the CoreOS architecture completely bans LLMs from touching CLI executables. We enforce a zero-trust model utilizing Native OAPI Tools behind a rigid Identity and Policy Gateway.

• Credential Decoupling: Tools are implemented natively at the gateway layer. The LLM generates the JSON business parameters but never sees, touches, or handles API tokens.
• Just-In-Time Context Routing: When the LLM requests an action, the underlying daemon intercepts the SenderId from the message context. It queries an internal Auth Store and injects the specific user's OAuth Access Token into the transport layer milliseconds before the HTTP execution. User contexts are physically isolated per request.
• Out-of-Band Approval Hooks: For any privilege escalation or data mutation, the gateway suspends the execution at the base layer. It forces an Approve/Deny prompt to the physical user's device. We do not trust the model; we mechanically block hallucination-driven executions.

Autonomous LLM CLI execution is amateur roleplay. Real enterprise AI infrastructure is built on the boring, unforgiving realities of permission isolation, concurrency locks, and strict state machine management. Stop building toys.

---

🇨🇳 中文翻译 (Chinese Translation)

厂商们正在疯狂鼓吹平台 CLI（飞书、钉钉）是 Agent 执行层的所谓“重大突破”。其预设极其幼稚：把大模型接入命令行，企业自动化就能自主运转。

在任何经历过生产环境毒打的架构师眼里，这就是纯粹的垃圾。向大模型暴露原生 CLI 执行文件，本质上是把一个单机版玩具伪装成 ToB 基础设施。这是一颗随时会引发状态污染和数据泄露的定时炸弹。

1. Token 焚烧与级联状态污染

指望大模型通过 ReAct 循环去动态解析 CLI Schema 并执行工具，是不可原谅的算力浪费。你是在烧 Token 让模型现场盲猜参数结构。

当你把泛化 CLI 的无界自由度交给大模型时，语法幻觉是必然的。漏掉一个参数或生成错误的查询语句，立刻就会触发 400 Bad Request 的重试死循环。更致命的是，如果幻觉生成了语法合法但业务错误的命令，脏数据就会被写回业务库，从而在整个自动化链路中引发级联故障。

生产环境的基线要求是绝对的确定性。工作流必须被 LangGraph 或严格的 SOP 固化为硬编码的 DAG（有向无环图）。大模型只能被严格限制在孤立的计算节点内，负责非结构化数据的转换。绝对禁止将执行运行时的最高控制权下放给大模型。

2. 多租户竞态条件

官方 CLI 工具的致命缺陷在于其单机版（Single-Player）基因。诸如 lark-cli 类的执行文件，重度依赖全局配置文件（如 ~/.config）或静态环境变量来进行鉴权。

把这种玩具部署到 50 人的企业 Slack 频道里。当员工 A 和员工 B 并发要求 Agent 获取涉密项目数据时，底层进程如何隔离他们的凭证？

如果你的 Agent 默认使用全局 Admin Token，权限边界会瞬间彻底崩塌，导致严重的跨租户数据泄露。如果你试图在并发请求中动态覆写全局环境变量，立刻就会引发竞态条件（Race Conditions）和多线程状态污染。任何缺乏请求级（Request-scoped）动态鉴权隔离机制的 Agent 基础设施，都是残次品。

3. 生产级标准：原生工具与身份网关

在 Limina Labs 的 CoreOS 架构中，我们彻底封杀了大模型接触 CLI 执行文件的路径。我们强制实行零信任模型，将原生 OAPI 工具置于严格的身份与策略网关（Identity and Policy Gateway）之后。

• 凭证彻底解耦：工具逻辑在网关层 Native 实现。大模型只负责生成 JSON 格式的业务参数，永远不可见、不可触碰、也不处理任何 API Token。
• JIT 上下文路由：当大模型发起动作请求时，底层守护进程会直接拦截消息上下文中的 SenderId。它会查询内部 Auth Store，在 HTTP 请求发出的前几毫秒，将特定用户的 OAuth Access Token 注入传输层。用户上下文在请求级别实现物理隔离。
• 带外审批拦截：针对任何提权或数据变更操作，网关会在底层直接挂起执行。系统强制向物理用户的设备推送 Approve/Deny 确认卡片。我们从不信任模型；我们通过机械机制直接阻断幻觉驱动的越权执行。

大模型自主操作 CLI 只是业余开发者的极客自嗨。真正的企业级 AI 基础设施，建立在枯燥且冷酷的权限隔离、并发锁和严苛的状态机管理之上。别拿玩具忽悠生产环境。