《Clawith 的真实谎言》¶

一个 AI Coding 项目的工程解剖

语言： English · 中文

关于本文的作者¶

本文的编写和分析，同样主要依赖大语言模型（LLM）完成。

研究过程中的证据收集、代码搜索、模式识别、因果推断以及文章撰写，均由大语言模型辅助人类研究者完成。这本身就是 AI Coding 案例研究的一个元层面：研究 AI Coding 项目后果的过程，本身也是 AI Coding 的产物。

我们并不回避这一事实。相反，它证明了本文的核心论点：AI Coding 可以快速产出在局部合理、经过验证的文本和代码，但最终判断——哪些事实值得发布、如何组织论证、对读者负什么责任——仍然需要人类做出。

在本文中，人类研究者负责：

确定研究方向和范围
决定哪些发现进入正式发布
评估披露风险
对发表的结论承担最终责任

大语言模型负责：

搜索和定位源码证据
识别代码模式
撰写分析草稿
格式化和组织文本

第一部分 · 研究原则¶

1. 我们研究的不只是一个项目¶

本项目以 Clawith 为案例，评估一个更普遍的问题：

当 AI Coding 让软件实现速度超过团队建立、维护和验证整体系统模型的速度时，可能发生什么？

研究目标不是单纯罗列 Clawith 的缺陷，也不是预先认定项目中的所有问题都由 AI 造成。

2. AI Coding 不被预设为原始原因¶

部分候选发现首先源自实现之前的选择，例如产品定位、领域概念、治理思想以及互相冲突的需求。无论代码由人还是 AI 编写，这些问题都可能存在。

因此，我们采用的工作模型不是：

AI Coding → 项目中的所有问题

而是：

含混或互相矛盾的产品方向
              ×
高速、局部、逐任务的实现方式
              ×
缺少对全局不变量的持续负责
              ↓
矛盾被大规模代码化、复制、遮蔽和放大

AI Coding 可能是加速器、放大器、实现形态塑造者或遮蔽物。它在每条发现中扮演什么角色，需要分别判断。

3. 我们区分事实与解释¶

发布内容严格区分以下层次：

项目声明：项目公开声称自己是什么；
代码与历史事实：源码和提交记录直接显示什么；
运行行为：在明确条件下能够复现什么；
解释与发现：这些事实说明了哪些产品或架构问题；
与 AI Coding 的关系：AI Coding 是产生、放大、塑造、遮蔽了问题，还是目前看不出直接关系。

仅凭代码特征不能证明某次修改由谁编写。我们不会把相关性写成 AI 作者身份的证明。

4. Clawith 是标本，不是最终目标¶

Clawith 具有真实项目所需的复杂度和一定公开关注度，并同时包含身份、权限、多 Agent 通信、工具、代码执行、外部集成和多租户行为。这些边界互相交叉，使它适合用于观察系统级后果。

研究最终要讨论的是更普遍的工程问题：局部合理的代码，并不保证系统在整体上自洽、可维护或安全。

第二部分 · 评估维度¶

一个 Agent 平台做两件事：运行 Agent，和 管理 Agent。以下维度不仅适用于 Clawith——你同样可以用它们审视任何 Agent 平台。

运行底座 —— 能不能跑好一个 Agent¶

维度	含义
1 · 认知管道与算力调度	你花多少钱，Agent 响应多快，结果质量好不好。
2 · 沙箱边界与租户隔离	你的 Agent 会不会在你的系统内部捣乱，破坏你的系统。
3 · 外部通信与网络可信度	别人能不能通过 Agent 侵入你的系统。

管理平台 —— 能不能管好一群 Agent¶

维度	含义
4 · 生命周期与可见性控制	你知不知道有多少 Agent、都在干什么、产出了什么。
5 · 数字资产与凭证治理	Agent 使用、管理的各种密钥、凭证，是不是会轻易被人偷走、滥用。
6 · 组织关系与协作拓扑	能不能实现角色划分、权限控制、Agent 协作。

独立信号 · 僵尸功能与实现债¶

信号	含义
产品演进是否收口	你看到的功能，是真的能用，还是没删干净的遗迹。

第三部分 · 完整索引¶

所有发现已通过源码核实（证据等级 F，分析基线 4f843556）。

维度 1 · 认知管道与算力调度（5 篇）¶

编号	文章	一句话
018	一根管道：所有工具输出都是对话	所有工具输出——stdout、stderr、文件内容——全部作为对话注入 `messages[]`，无独立审计日志
019	一个什么都往里扔的垃圾桶	soul.md、memory.md、skills/、focus、triggers、enterprise_info 全部拼进一条 system message——无分层、无缓存
020	伪缓存与心跳税：如何烧掉你的钱	Prompt 缓存仅 Qwen 启用；心跳每 4 小时触发一次完整 LLM 会话，零并发控制
021	当"一切皆文件"变成"一切皆灾难"	Memory 是一个全局 markdown 文件，所有用户共享，注入 system prompt——任何用户都能通过对话污染它
022	零加工哲学：一句设计原则如何毁掉整个运行时	前四篇的共同根因：CLA.md 声明「一套文件工具覆盖所有需求」——AI 忠实执行了这一原则

维度 2 · 沙箱边界与租户隔离（2 篇）¶

编号	文章	一句话
001	路径边界：18 处同模式脆弱检查	代码库中 18 处 `str(path).startswith(str(base))`，全部缺少路径分隔符检查——无共享抽象
002	工具/沙箱配置更新存在 IDOR	任何已登录用户都能修改任意 Agent 的沙箱类型、URL 和 API Key——端点仅校验了用户已登录

维度 3 · 外部通信与网络可信度（1 篇）¶

编号	文章	一句话
003	飞书 Event Webhook 零验签	`verification_token` 和 `encrypt_key` 已存入数据库但从未被读取——知道 `agent_id` 就能伪造飞书事件

维度 4 · 生命周期与可见性控制（2 篇）¶

编号	文章	一句话
005	比不做更坏：Dashboard 的虚假在线	心跳每 60 秒查 DB、组装上下文、调用 LLM——但从不更新 `agent.status`，Dashboard 永远显示「在线」
006	全部 ≠ 全部：系统性的"全量"语义不一致	活动流、Directory、`custom` 模式都声称展示「全部」——但全都漏掉了关键部分

维度 5 · 数字资产与凭证治理（2 篇）¶

编号	文章	一句话
009	Gateway API Key 的明文存储与非恒定时间比对	验证先试明文，用 Python `==`（非恒定时间），SHA256 无盐——注释将明文标为「新行为」
010	Gateway API Key：新旧逻辑并存	创建用 SHA256 哈希；验证先试明文——两条路径不一致，迁移无完成计划

维度 6 · 组织关系与协作拓扑（9 篇）¶

编号	文章	一句话
004	actor 缺失时回退 Agent 创建者身份	`actor_user_id` 为 `None` 时静默回退到 `agent.creator_id`——混淆代理人，授予未授权管理员权限
007	资源归属：未形成的统一模型	8/13 资源模型缺少 `tenant_id`；凭证散落 5+ 处；产出物使用 4 种不同持久化方式
008	A2A 委托与群聊：脱离正式工作模型	委托运行绕过 Focus 工作项模型和 OKR 系统，不写 `AgentActivityLog`——产生不可审计的幽灵工作
011	数字员工，还是个人助理？	README 承诺「数字员工」，但代码无 `agent` RBAC 角色，身份依附 `creator_id`，配额挂在 User 表上
012	可见 ≠ 可管理：被混淆的"可见"语义	「可见」同时承载可发现、可联系、可委派三重含义——代码没有独立的委托授权检查
013	能通信 = 能委派：A2A 通信与任务委派权未分离	`send_message_to_agent` 将 `notify`、`consult`、`task_delegate` 三种模式塞进一个工具，共用一道 `can_contact` 门禁
014	没有任何权限控制的系统：company 模式下的全公司同权	`company` 模式下所有用户权限完全相同——无部门、无角色层级，`use`/`manage` 区分被 A2A 委托绕过
015	既瞎又聋的私有 Agent：private 模式的隔离悖论	`private` Agent 只能看到同创建者的 `private` Agent——用户被迫在「安全但无用」和「有用但裸奔」之间二选一
016	custom 模式形同虚设：可见性控制的幻觉	`custom` 模式控制的是「你能看谁」而非「谁可以看你」——任何管理员都能从任意非 private Agent 的视角添加你

独立信号 · 僵尸功能与实现债（1 篇）¶

编号	文章	一句话
017	relationship 迁移：未收口的半成品	9 个 REST API 和约 700 行前端代码在迁移后完整保留——未使用、未清理，丰富的关系模型被降级为硬编码 `"collaborator"`
---

第四部分 · 总结¶

（待写）