pi-amq 0.1.2 → 0.1.3

package/docs//346/250/241/345/236/213/345/274/272/345/272/246/344/270/216Harness/345/244/215/346/235/202/345/272/246.md

@@ -1,1011 +0,0 @@
-> From: https://chatgpt.com/c/6a7db1e6-c83c-83ea-8cec-392ffb7e3183
-
-# you asked
-
-message time: 2026-08-13 05:00:03
-
-你觉得是 模型越强 harness 越少约束
-还是模型越强 harness 越复杂
-
----
-
-# chatgpt response
-
-我更倾向于：
-
-> **模型越强，Harness 应该越少“行为级约束”，但越多“系统级约束”。**
->
-> 所以不是 Harness 单纯变少，也不是单纯变复杂，而是 **复杂度从 prompting / workflow 编排，迁移到 runtime / policy / verification / observability**。
-
-可以把 Harness 分成两类来看。
-
-### 1. 模型能力越强，这部分应该越来越少
-
-比如这种：
-
-- 规定先读文件 A，再读文件 B
-- 强制每一步输出 JSON
-- 写死 20 步 workflow
-- `if bug -> call X -> then call Y`
-- 给模型塞大量「应该如何思考」的 prompt
-- 人工拆解非常细的 task graph
-- 用状态机模拟模型本来就能做的推理
-- “先分析、再计划、再执行、再反思三次”
-
-这些本质上都是 **补偿模型能力不足的 scaffolding**。
-
-模型变强以后，继续这样做反而会降低能力。
-
-例如：
-
-```text
-弱模型：
-
-Issue
- ↓
-Classify
- ↓
-Planner
- ↓
-Task decomposition
- ↓
-Router
- ↓
-Coder
- ↓
-Reviewer
- ↓
-Fixer
-```
-
-模型足够强之后，很多时候可以变成：
-
-```text
-Issue
- ↓
-Agent
- ↓
-Result
-```
-
-Agent 自己决定：
-
-- 要不要搜索
-- 要不要拆 task
-- 要不要跑测试
-- 要不要调用另一个 agent
-- 要不要修改计划
-
-这部分我认为 **一定会收缩**。
-
----
-
-但另一边，真正生产级 Harness 反而会变得更复杂。
-
-不是为了教模型「怎么干活」，而是为了控制：
-
-> **模型能干什么、干过什么、结果是否可信、失败后怎么办。**
-
-也就是：
-
-```text
-                    ┌──────────────┐
-                    │    Model     │
-                    │ autonomous   │
-                    └──────┬───────┘
-                           │
-           ┌───────────────┼───────────────┐
-           ↓               ↓               ↓
-       Capability        Context         Delegation
-       boundary          assembly         / tools
-           │               │               │
-           └───────────────┼───────────────┘
-                           ↓
-                      Execution
-                           │
-              ┌────────────┼────────────┐
-              ↓            ↓            ↓
-          Event log      Evidence     Sandbox
-              │            │            │
-              └────────────┼────────────┘
-                           ↓
-                     Verification
-                           │
-                    commit / reject
-```
-
-这部分随着 Agent 能力增强，重要性反而增加。
-
-因为能力越强：
-
-```text
-能力 ↑
-自主决策空间 ↑
-可采取动作数量 ↑
-长期任务长度 ↑
-并行度 ↑
-影响范围 ↑
-```
-
-所以：
-
-```text
-failure surface ↑
-```
-
-这和操作系统很像。
-
-我们不会因为 application 越智能，就把：
-
-- process isolation
-- permission
-- filesystem ACL
-- transaction
-- audit log
-- resource quota
-
-删掉。
-
-恰恰相反。
-
----
-
-## 一个很关键的区分：Mechanism vs Policy
-
-未来好的 Harness 应该尽量：
-
-> **减少 Policy，强化 Mechanism。**
-
-例如不要写：
-
-```text
-你必须：
-1. 读 README
-2. 搜索 Foo
-3. 修改 Bar
-4. 执行 test
-5. review
-```
-
-这是 Harness 在替模型做决策。
-
-而应该提供：
-
-```text
-Goal:
-  fix issue #123
-
-Capabilities:
-  read_repo
-  edit_repo
-  run_tests
-  spawn_agent
-
-Constraints:
-  cannot push main
-  max $5
-  max 30 min
-  no production credentials
-
-Acceptance:
-  test A passes
-  test B passes
-  lint passes
-
-Commit:
-  requires approval
-```
-
-至于：
-
-```text
-先读哪个文件
-要不要开 sub-agent
-搜什么
-修改几个文件
-跑哪些 intermediate tests
-```
-
-让模型自己决定。
-
-这才是强模型时代 Harness 的正确 abstraction boundary。
-
----
-
-## 我甚至认为会出现一个 U 型曲线
-
-如果定义 Harness complexity：
-
-```text
-                    production harness
-                          /
-                         /
-                        /
-           ____________/
-          /
-         /
- weak model       strong model
-```
-
-实际上更准确的是拆成两个曲线：
-
-```text
-Procedural orchestration complexity
-██████████████████
-██████████████
-██████████
-██████
-██
-──────────────────────→ model capability
-
-
-Runtime/governance complexity
-
-██
-████
-████████
-████████████
-████████████████
-──────────────────────→ model capability
-```
-
-最终总复杂度甚至可能上升。
-
-但 **复杂的是基础设施，不是 agent instructions**。
-
-这点很重要。
-
----
-
-### 举一个 coding agent 的例子
-
-早期 Harness：
-
-```text
-1. inspect git status
-2. read issue
-3. grep symbols
-4. create plan
-5. ask approval
-6. edit
-7. run unit tests
-8. inspect diff
-9. run lint
-10. fix
-11. summarize
-```
-
-强模型时代我更希望：
-
-```text
-Objective:
-  Implement issue #123
-
-Definition of Done:
-  - specified behavior works
-  - existing tests pass
-  - new behavior has tests
-  - no unrelated changes
-
-Permissions:
-  repo.write
-  shell.exec
-
-Forbidden:
-  network.secret_access
-  git.push.main
-
-Budget:
-  1M tokens
-  2h compute
-
-Commit condition:
-  verifier passes
-```
-
-Harness 不再关心模型是：
-
-```text
-grep → edit → test
-```
-
-还是：
-
-```text
-read → spawn agent → benchmark → edit → test
-```
-
-这是模型的 implementation detail。
-
-这其实与软件工程里的一个基本思想完全一致：
-
-> **依赖 contract，而不是依赖 implementation。**
-
----
-
-## Agent Harness 最终可能很像 OS + Database，而不是 Workflow Engine
-
-这是我现在越来越确定的判断。
-
-早期大家把 Agent Harness 做成：
-
-```text
-LangGraph
-DAG
-state machine
-workflow
-router
-```
-
-因为模型不可靠，所以系统必须告诉模型下一步是什么。
-
-强模型时代更自然的模型会是：
-
-```text
-Agent Runtime
-    +
-Capability System
-    +
-Durable State
-    +
-Event Log
-    +
-Policy Engine
-    +
-Verifier
-```
-
-Agent 自己产生下一步。
-
-也就是说：
-
-```text
-旧范式：
-
-Harness owns control flow
-Model executes nodes
-```
-
-逐渐变成：
-
-```text
-新范式：
-
-Model owns control flow
-Harness owns invariants
-```
-
-我认为这是最核心的变化。
-
----
-
-### 一句话判断
-
-如果有人说：
-
-> 模型越强，所以以后 Harness 会消失。
-
-我认为是错的。
-
-如果有人说：
-
-> 模型越强，所以以后需要更复杂的 workflow / prompt / agent graph。
-
-我也认为是错的。
-
-更准确的是：
-
-> **Strong models kill orchestration complexity, but create governance complexity.**
-
-或者：
-
-> **Harness 从“告诉 Agent 怎么做”，演化为“定义 Agent 可以做什么，以及什么结果算完成”。**
-
-所以未来优秀 Harness 的衡量标准可能不是「支持多少 workflow node」，而是：
-
-**最小控制面 + 最大自主空间 + 强不变量。**
-
-这也是我认为做 Agent Runtime 时最值得坚持的一条设计原则。
-
-### What questions should I have asked?
-
-1. **哪些东西应该成为 Harness 的 invariant，哪些应该彻底交给模型自主决定？**
-2. **如果 Agent 自己拥有 control flow，还需不需要 DAG / FSM，它们应该退到哪一层？**
-
----
-
-# chatgpt response
-
-需要，但**角色会发生根本变化**。
-
-我的结论是：
-
-> **DAG / FSM 不应该继续描述 Agent「怎么完成任务」，而应该描述系统「哪些状态转换是合法的」。**
->
-> 换句话说：**DAG 从 execution plan 退到 dependency/evidence graph；FSM 从 workflow engine 退到 lifecycle/invariant enforcement。**
-
-这两者都不会消失，只是不再拥有 Agent 的微观 control flow。
-
----
-
-## 1. 先区分两种 Control Flow
-
-传统 workflow agent：
-
-```text
-Harness owns control flow
-
-START
-  ↓
-Analyze
-  ↓
-Plan
-  ↓
-Implement
-  ↓
-Test
-  ↓
-Review
-  ├── fail ──→ Implement
-  ↓ pass
-Done
-```
-
-这里 Harness 决定：
-
-> Agent 下一步应该做什么。
-
-这其实是把 Agent 当成一个 function executor：
-
-```text
-result = agent.execute(node)
-```
-
-对于越来越强的模型，我认为这个 abstraction 会逐渐过时。
-
-更合理的是：
-
-```text
-Harness
-  │
-  │ objective + constraints + capabilities
-  ▼
-┌─────────────────────────────┐
-│ Agent                       │
-│                             │
-│ inspect repo                │
-│   ↓                         │
-│ make hypothesis             │
-│   ↓                         │
-│ run test                    │
-│   ↓                         │
-│ inspect source              │
-│   ↓                         │
-│ spawn sub-agent             │
-│   ↓                         │
-│ change implementation       │
-│   ↓                         │
-│ test                        │
-│   ↓                         │
-│ realize assumption wrong    │
-│   ↓                         │
-│ change plan                 │
-│   ↓                         │
-│ ...                         │
-└─────────────────────────────┘
-```
-
-里面这坨东西：
-
-> **应该逐渐成为 Agent private control flow。**
-
-Harness 不需要知道。
-
----
-
-# 2. 那 FSM 去哪里？
-
-FSM 应该退到 **业务对象 / 生命周期层**。
-
-比如一个 WorkItem：
-
-```text
-              ┌─────────┐
-              │  READY  │
-              └────┬────┘
-                   │ claim
-                   ▼
-              ┌─────────┐
-              │ RUNNING │
-              └────┬────┘
-                   │ submit evidence
-                   ▼
-             ┌───────────┐
-             │ VERIFYING │
-             └─────┬─────┘
-               pass│   │fail
-                   │   └──────────┐
-                   ▼              ▼
-              ┌─────────┐    ┌─────────┐
-              │  DONE   │    │ RUNNING │
-              └─────────┘    └─────────┘
-```
-
-这里 FSM 不关心：
-
-```text
-Agent 搜了什么
-Agent 怎么 reasoning
-Agent 调了几个工具
-Agent 修改了几个文件
-Agent 有没有开 sub-agent
-```
-
-它只负责：
-
-```text
-RUNNING → VERIFYING
-```
-
-是否合法。
-
-比如：
-
-```text
-RUNNING → DONE
-```
-
-直接禁止。
-
-必须：
-
-```text
-RUNNING
-   ↓
-VERIFYING
-   ↓
-DONE
-```
-
-而且：
-
-```text
-VERIFYING → DONE
-```
-
-要求：
-
-```text
-required_evidence.exists
-&& verifier.passed
-&& open_blocking_findings == 0
-```
-
-这就是 **FSM = invariant enforcement**。
-
-它不是：
-
-> 下一步请调用 coding agent。
-
-而是：
-
-> 你想怎么干随便，但系统状态只能按照这些规则变化。
-
-这非常像数据库。
-
-数据库不会告诉 application：
-
-> 先 INSERT A，再 SELECT B，再 UPDATE C。
-
-但它会说：
-
-```sql
-FOREIGN KEY
-UNIQUE
-CHECK
-NOT NULL
-TRANSACTION
-```
-
-**FSM 应该越来越像数据库 constraint，而不是 BPMN workflow。**
-
----
-
-# 3. DAG 也一样：从 Execution DAG 退到 Dependency DAG
-
-现在很多 Agent system：
-
-```text
-              Plan
-               │
-       ┌───────┼───────┐
-       ▼       ▼       ▼
-    Backend  Frontend  Test
-       │       │       │
-       └───────┼───────┘
-               ▼
-             Review
-               │
-               ▼
-             Deploy
-```
-
-然后 scheduler：
-
-```text
-topological sort
-ready queue
-worker pool
-```
-
-决定 Agent 下一步干什么。
-
-这种 DAG 对 deterministic workflow 很合理。
-
-但对于强 Agent，我不会让它描述：
-
-```text
-grep
- ↓
-read file
- ↓
-edit
- ↓
-test
- ↓
-review
-```
-
-因为现实 coding task 的 dependency graph 很多时候是**执行过程中才发现的**。
-
-例如：
-
-```text
-Fix login bug
-     │
-     ├──发现 schema 问题
-     │
-     ├──发现 migration 问题
-     │
-     └──发现 Android client compatibility
-```
-
-你在任务开始前根本不知道 DAG。
-
-如果强行 upfront planning：
-
-```text
-LLM
- ↓
-generate DAG
- ↓
-execute DAG
-```
-
-其实是在假设：
-
-> planning knowledge 在执行前已经充分。
-
-这通常是错的。
-
----
-
-# 4. DAG 真正应该留下的是 dependency / obligation
-
-例如：
-
-```text
-                    Feature
-                       │
-           ┌───────────┼───────────┐
-           ▼           ▼           ▼
-        Android       iOS        Backend
-           │           │           │
-           └───────────┼───────────┘
-                       ▼
-                Integration Test
-                       │
-                       ▼
-                  Acceptance
-```
-
-这里表达的不是：
-
-> Agent 必须按照这个执行顺序工作。
-
-而是：
-
-> Acceptance 的成立依赖这些 evidence。
-
-也就是：
-
-```text
-Acceptance
-    requires
-       ├── AndroidEvidence
-       ├── IOSEvidence
-       ├── BackendEvidence
-       └── IntegrationEvidence
-```
-
-这是一个非常重要的转变：
-
-```text
-Execution DAG
-    ↓
-
-Evidence DAG
-Dependency DAG
-Obligation DAG
-```
-
-Agent 可以：
-
-```text
-先写 Backend
-```
-
-也可以：
-
-```text
-先调查 iOS
-```
-
-甚至：
-
-```text
-同时 spawn 3 agents
-```
-
-Harness 不在乎。
-
-Harness 只保证：
-
-```text
-IntegrationEvidence
-```
-
-不能在 prerequisites 不满足时被认定为有效。
-
----
-
-# 5. 所以我会把整个系统分成三层
-
-我认为这是比较稳定的 architecture：
-
-```text
-┌──────────────────────────────────────┐
-│            Objective Layer           │
-│                                      │
-│  Goal / Acceptance / Constraints     │
-│  Policy / Budget / Permissions       │
-└──────────────────┬───────────────────┘
-                   │
-                   ▼
-┌──────────────────────────────────────┐
-│             Agent Layer              │
-│                                      │
-│       autonomous control flow        │
-│                                      │
-│  reason                              │
-│  plan                                │
-│  replan                              │
-│  search                              │
-│  tool use                            │
-│  spawn agents                        │
-│  retry                               │
-│  experiment                          │
-│                                      │
-└──────────────────┬───────────────────┘
-                   │ actions / evidence
-                   ▼
-┌──────────────────────────────────────┐
-│            Runtime Layer             │
-│                                      │
-│ FSM        lifecycle invariants      │
-│ DAG        dependencies              │
-│ Policy     capability boundaries     │
-│ Ledger     durable history           │
-│ CAS        concurrency control       │
-│ Verifier   evidence validation       │
-│ Budget     resource limits           │
-└──────────────────────────────────────┘
-```
-
-中间 Agent Layer 是**自由度最高**的。
-
-上下两层反而应该 deterministic。
-
-可以概括成：
-
-```text
-        Declarative
-            ↓
-Objective / Contract
-
-        Autonomous
-            ↓
-         Agent
-
-        Deterministic
-            ↓
-Runtime / Invariants
-```
-
-这比：
-
-```text
-Workflow Engine
-      ↓
-Agent
-      ↓
-Workflow Engine
-      ↓
-Agent
-```
-
-更适合强模型。
-
----
-
-## 6. 但 DAG Scheduler 并不会完全消失
-
-这里需要避免走到另一个极端。
-
-如果有**天然 deterministic dependency**，还是应该交给传统 scheduler。
-
-比如：
-
-```text
-Build Backend
-Build Android
-Build iOS
-      │
-      ▼
-Integration Test
-      │
-      ▼
-Release
-```
-
-这些 dependency 是客观存在的。
-
-不要让 LLM 每次重新推理：
-
-> Integration Test 能不能运行？
-
-这是浪费 token，而且降低可靠性。
-
-因此原则应该是：
-
-> **确定性的东西不要交给模型；不确定性的东西不要硬编码成 workflow。**
-
-我认为这是整个 Agent architecture 最重要的分界线之一。
-
-例如：
-
-| 问题 | 谁负责 |
-|---|---|
-| 下一步应该调查哪个文件？ | Agent |
-| 是否需要重新规划？ | Agent |
-| 是否需要 sub-agent？ | Agent |
-| 如何修 bug？ | Agent |
-| B 是否依赖 A？ | DAG |
-| A 未完成时 B 能否 commit？ | DAG / invariant |
-| 当前 WorkItem 是否可进入 Done？ | FSM |
-| Agent 是否能访问 production？ | Policy |
-| 两个 Agent 能否同时修改状态？ | CAS / transaction |
-| 测试结果是否满足 acceptance？ | Verifier |
-| 失败三次之后怎么办？ | Runtime policy |
-
-最后那个尤其有意思。
-
-不要写：
-
-```text
-FSM:
-coding_failed
- → retry_1
- → retry_2
- → retry_3
- → human
-```
-
-除非“三次”本身是业务规则。
-
-更好的抽象往往是：
-
-```text
-Runtime:
-budget exhausted
-confidence too low
-no progress detected
-permission required
-irreversible action
-```
-
-然后进入：
-
-```text
-BLOCKED / NEEDS_ATTENTION
-```
-
-而不是把 Agent 的 retry strategy 都塞进 FSM。
-
----
-
-# 7. 最终判断标准
-
-以后设计 Harness 时，我会问一个问题：
-
-> **这个状态/边是世界的客观约束，还是我们在替 Agent 猜它应该怎么工作？**
-
-如果是：
-
-```text
-PR merge 前必须 CI pass
-payment 前必须 approval
-integration 必须等 dependency ready
-acceptance 必须没有 blocking finding
-```
-
-放进：
-
-**FSM / DAG / invariant。**
-
-如果是：
-
-```text
-先搜索代码
-然后写 plan
-然后改代码
-然后跑 test
-失败就反思
-然后再搜索
-```
-
-尽量：
-
-**删掉，交给 Agent。**
-
-因此最终可能不是：
-
-```text
-DAG orchestrates Agents
-```
-
-而是：
-
-```text
-            Objective
-                │
-                ▼
-        ┌───────────────┐
-        │ Autonomous    │
-        │ Agent / Team  │
-        └───────┬───────┘
-                │
-       proposes mutations
-       produces evidence
-                │
-                ▼
-┌────────────────────────────────┐
-│ Deterministic Control Plane    │
-│                                │
-│ FSM     legal transitions      │
-│ DAG     dependencies           │
-│ Policy  permissions            │
-│ CAS     concurrency            │
-│ Ledger  history                │
-│ Verify  acceptance             │
-└────────────────────────────────┘
-```
-
-我会把这个原则压缩成一句：
-
-> **Agent owns strategy; Harness owns truth.**
-
-这也是为什么我认为，强模型时代 **DAG/FSM 不会消失，而是从 orchestration primitive 降级成 consistency primitive**。
-
----
-Powered by [AI Exporter](https://saveai.net)