Engineering Pillars

让 LLM 在真实软件工程里更可靠的四根工程化支柱

路由与七层闭环解决的是"谁来做、怎么收口"，但这不够。真实软件工程里 LLM 的痛点是：实现前不约束、自产自审、旧路径永不退休、永远"再来一轮"。这四根支柱就是针对这四个痛点设计的工程化门禁，也是本项目区别于"换几个角色回答"的核心差异化所在。

P1

Harness 工程约束门禁

Engineering Constraint Gate
6 个 code-facing bundle

6 个 code-facing bundle（plan-first-build / product-spec-deliver / audit-fix-deliver / govern-change-safely / root-cause-remediate / direct-execution）执行前必须先创建或刷新 .skill-harness/engineering-constraints.md，把"实现前先约束"从建议变成硬门禁。Agent 可以先看代码，但在工程约束明确之前不能开始改生产文件。

必填章节
  • Scope
  • Non-Negotiable Constraints
  • Forbidden Changes
  • Verification Evidence
  • Rollback And Stop Conditions
P2

Team Engine Lite 对抗式验收

Worker / Verifier / Lead Separation
11 状态机 · 5 标准对象

Worker 只产不验、Verifier 只验不产、Lead 只能基于 DeliveryCycleReport 接受。配合 3 级 runtime claim（real_subagent_runtime / single_backend_multi_session / soft_orchestration_only），禁止把角色扮演误称为真实多 Agent runtime。没有宿主 spawn / wait / merge 证据时，声明始终保持 soft_orchestration_only。

标准对象
  • WorkOrder
  • ImplementationOutput
  • VerificationReport
  • RemediationPatch
  • DeliveryCycleReport
P3

Anti-Entropy 反熵治理

Anti-Entropy Governance
delete-first / compat-exception / confirmation-first

遇到 duplicate owner、fallback、adapter、guard 或兼容路径增长时，先按目标分类（code-retirement / contract-carrying-code / derived-state / persistent-state），再选路径：delete-first（能删就删）、compat-exception（保留兼容但登记例外）、confirmation-first（未知依赖先问人）。核心原则：未知依赖不等于活跃依赖证据。

触发信号
  • duplicate owner
  • fallback growth
  • adapter / guard 膨胀
  • delete vs compat 边界
  • source-of-truth 删除边界
P4

Self-Optimization 自优化循环

Bounded Iteration + Mutation Catalog
live ≤3 · offline ≤120 · same-hypothesis ≤2

可对自身的 routing-rules.json / regression-cases.json / evals.json 做 JSON-aware 确定性自优化。Live 模式最多 3 轮、Offline 模式最多 120 轮、同一假设最多 2 次重试。所有 rollback / keep / pivot / resume / hold→bootstrap→auto-run 路径都可以通过 offline loop drill 离线验证，不让自优化变成"无限自转"。

Mutation 操作族
  • json_set
  • json_merge
  • json_delete
  • append_unique
  • regex_replace

六大支柱关系图

Six Pillars Hierarchy

本项目的工程化能力由六大支柱构成，分三个层级：基础层解决"谁来做、怎么收口"，工程层解决"实现前约束、验收时对抗"，治理层解决"旧路径退休、自身可优化"。

Routing 路由
8 lead · 13 语言 profile
7 Closures 七层闭环
Planning → Feedback
↓ 工程化门禁层 ↓
P1 Harness
实现前约束
P2 Team Engine Lite
对抗式验收
↓ 治理与自优化层 ↓
P3 Anti-Entropy
反熵治理
P4 Self-Optimization
自优化循环

Harness 门禁流程

Constraint Gate Flow

code-facing bundle 在进入实现前必须经过 Harness 门禁。Release / beta / post-release 路由在只做证据收集时可以跳过门禁，但一旦进入实现阶段就必须补上。

收到 code-facing 任务
→
路由到 bundle
→
Harness Constraint Gate
→
init_harness_constraints.py
→
engineering-constraints.md
→
Team Engine Lite
→
DeliveryCycleReport

工程化能力对比

Engineering Capability Comparison
能力 本项目 普通多专家提示词 通用 Agent 框架
工程约束门禁 5 必填章节 + 6 bundle 强制 无 无
对抗式验收 Worker/Verifier/Lead 分离 自产自审 部分（critic 角色）
反熵治理 3 路径 + 4 类目标 不断加 fallback 无
自优化循环 bounded iteration + drill 无 无
Runtime 诚实 3 级 runtime claim 角色扮演误称多 Agent 部分声明 real runtime
完成证据 7 字段 schema "觉得好了"就完成 部分（task output）

自动化脚本支撑

45+ Automation Scripts

四根支柱不是停留在文档上的概念，而是由 45+ 个 Python 脚本支撑的可执行机制。这些脚本覆盖初始化、校验、迭代、演练、发布、恢复全链路，确保工程化门禁可以被机器执行和验证。

核心脚本
  • init_harness_constraints.py
  • check_harness_health.py
  • run_release_gate.py
  • run_iteration_loop.py
  • run_offline_loop_drill.py
  • run_team_engine_drill.py
  • verify_action.py
  • verify_completion_evidence.py
  • route_request.py
  • validate_virtual_team.py