EFFICIENT 系统

EFFICIENT 是团队的系统，其中大部分不是我做的。后端、各个门户和店面属于做它们的人。我负责的是它们共同依赖的那一层：装着工程契约的 efficient-harness，以及执行这份契约的 agent 工作流 skills。这一页就按这个顺序讲 —— 先讲架构，因为契约只有对着它治理的东西才读得懂，然后才是契约本身。

后端持有领域与权限的真值，每个客户端消费它的契约，而不是重述一遍。shell 是各门户共用的 UI kit。Harness 完全不属于运行时 —— 没有东西 import 它，也没有东西部署它。它只是被读。

Caddy 终结 TLS，交给一个 ASGI server —— gunicorn 配 uvicorn worker —— REST 和 WebSocket 在同一个进程里跑。请求属于哪个租户是在中间件栈里决定的，早于任何碰 ORM 的代码：第四个中间件把 Host 解析成 public schema 里的一行，然后设置 Postgres 的 search_path。认证发生在更后面、在视图内部，因为 DRF 跑在 Django 中间件之后 —— 所以租户范围永远不是「你是谁」的函数。

硬性的数据隔离是产品约束，不是工程偏好：没有共享表。一个 Postgres，一个装租户注册表的 public schema，每个客户一个 schema，由中间件按域名选中。这个模型坚决不肯混淆的是租户和公司实体 —— 租户是客户、是隔离边界；公司实体是租户内部的法人实体，一个租户可以有很多个。把两者混为一谈，等于把默认公司当成租户键，而这条边界一旦丢了就找不回来。

门户里没有任何轮询。一次 ORM save 触发信号，模型不在实体映射表里就直接丢弃，活下来的按请求去重 —— 同一个事务里存一次和存四十次，产出的都是一次广播，而且要等响应提交之后才发出。消费端故意做得很笨：它只知道一个租户组，转发一条三个字段的消息，剩下的由客户端决定该让什么缓存失效。

优先级从左到右，永不反转：用户高于仓库，仓库高于 Harness，Harness 高于 agent 自己的默认行为。检索到的内容 —— issue 正文、网页、文档 —— 都是数据，无法授予它本来没有的权限。

这就是整个方法，它的价值在于它拒绝合并的那部分。报告差异和消除差异是两个 skill、两份产出 —— 因为一个既能报告又能修改的工作流，早晚会把标准改成它看到的样子。

一个在错误 prompt 上触发的 skill，比一个永远不触发的更糟 —— 因为读者分不清这是工作流没做好，还是它本来就不该出现在这里。所以每个 skill 都带一个 eval 文件：必须触发的 prompt，和必须不触发的 prompt，中英文都有，每条都写明期望的行为，由 CI 打分。真正起作用的是那些「不该触发」：ui:normalize 不能闯进只做审计的请求，contract:evolve 不能闯进不改契约的重构，workspace:doctor 不能闯进任何会改状态的操作。这些用例就是把边界写成可执行的东西 —— 而边界只有这一种形态，能熬过一年的变更。