Lucid 驗證了 Agent 能在使用者離開後繼續工作

強大的 Local Harness 還不是 Product Service。Lucid 成為缺少的 Production Boundary 壓力測試：Durable Scheduling、Isolated Execution、狹窄的 Product Authority、Process 消失後的 Recovery，以及不會把沉默誤認為成功的 User-facing Outcome。

目前狀態 · 2026 年 9 月

Lucid 是實驗性的 Personal-agent Deployment 與 Engineering Proof，不是公開可用的產品，也不是 Heddle Managed Service。以下證據是在 2026 年 9 月 2 日以前，於已部署的 Lucid、Coordinator 與 Managed Runtime Stack 中實際觀察。

作者 Jay / Fienna Liang發布 2026年9月3日更新 2026年9月3日

理解 Runtime 放置方式

Lucid Agent 在 Browser 關閉後因排程醒來，最後 Settlement 為沒有新 Finding 的流程圖 — 已部署實證跨越了 Timer-due Coordinator Claim、Managed Isolated Runtime、固定 Lucid Event Horizon、Scoped Tool 與 Truthful No-finding Settlement，全程不需要 Foreground Interaction。

產品: Personal Delegated-discovery Workspace
執行: 由 Coordinator 排程的隔離 Heddle Runtime
結果: 沒有開著 Browser 仍能執行背景工作

Local Agent Loop 不等於可部署的產品邊界

Local Harness 可以執行工具並保存 Conversation，但 Product Autonomy 會帶來另一組責任：工作需要 Durable Owner、對目前 Product State 的 Bounded View、Process Replacement 後的 Recovery，以及在 Browser 與原始 Request 都已消失後仍可信的 Terminal Result。

Lucid 也不能靠把 Database Credential 交給 Runtime，或把 Product Policy 複製進 Generic Scheduler 來解決。Lucid 必須繼續擁有 User、Interest、Message、Finding、Event Horizon、Idempotent Effect，以及 UI 所理解的 Complete；Heddle 與 Execution Host 則必須擁有可重用的 Execution Mechanics，而不成為產品本身。

User-facing Loop 必須驗證什麼

目標不是讓 Background Process 看起來很忙。Agent 必須維持 Continuity、只對授權狀態行動，並在沒有值得做的事情時保持克制。

使用者可以保存 Interest、離開 Browser，並讓 Scheduled Check 獨立持續。
Foreground Check now 與 Timer-due Wake 會進入同一套 Durable Product-work Lifecycle。
每次 Attempt 讀取固定 Event Horizon，而不是無界且持續變動的世界。
Agent 會記錄有來源的 Finding、有限的 Communication，或明確 No-finding Outcome。
Failure 與 Interruption 會保留尚未消費的 Product Work，而不是樂觀地推進 Cursor。
產品呈現可理解的 Activity，而不是 Raw Scheduler 或 Model Trace。

Lucid、Heddle Coordinator 與 Execution Host，以及 Scoped Product MCP Tool 之間 Ownership Boundary 的架構圖 — Lucid 保留 Identity、Canonical State、Product Effect 與 User-facing Truth；Execution Stack 只取得 Signed Scope 與 Narrow Capability，而不是 Lucid Database Credential。

Scheduling、Execution 與 Product Truth 維持分離

已部署路徑組合了三個不同 Owner。每一層各自執行一種事實，而不是共享一個過度膨脹的 Control Plane。

01Identity + Product Truth
Lucid Product
擁有 User、Interest、Event Horizon、Finding、Product Tool、Durable Effect、Cursor Advancement、Authenticated UI，以及 Complete 的產品意義。
02Durable Work Ownership
Heddle Coordinator
擁有 Schedule、Run Request、Claim、Fencing、Recovery、Bounded Concurrency、Checkpoint 與最終 Heddle Task Settlement。
03Isolated Execution
Execution Host Runtime
驗證 Signed Scope、執行一次 Bounded Heddle Model／Tool Loop、串流有序 Activity、處理 Cancellation，且不取得 Lucid Database Credential。

Execution Service 沒有變成產品本身

Lucid 只暴露單次 Claimed Attempt 所需的 Product Fact 與 Effect。Heddle 提供 General Lifecycle，Execution Host 提供隔離的執行空間。

Heddle + Execution Host 提供

Durable Task Scheduling、Run Request、Claim、Lease、Fencing、Recovery 與 Checkpoint
一次 Bounded Model／Tool Execution、Cancellation 與 Truthful Terminal Outcome
Signed Execution Identity 與精確的 Invocation-scoped MCP Capability
把 Temporary File 與 Process 和 Product Backend 隔離
公開 Adopter Contract，不要求 Adopter Import 私有 Host Code

Lucid 保留

User 與 Agent Identity、Authenticated Product Route 與 Product Policy
Canonical Event、Current Interest、Fixed Work Horizon 與 Unread Cursor
Product MCP Schema、Visibility Rule、Validation 與 Idempotent Effect
Finding、Communication、No-action、Retry 與 Product Settlement Semantics
User-facing Activity 與所有 Product UI 決策

Lucid 把 Adopter Friction 轉成可重用 Runtime Contract

這次整合反覆暴露了原本每個產品都必須重做的 Lifecycle Code。Generic Correctness 被提升到 Heddle 或 Execution Host；Lucid-specific Meaning 則留在 Lucid。

由整合強化的可重用機制

可 Coalesce 且不遺失較新 Intent 的 Durable Run Request
Claim Identity、Stale-writer Fencing、Interrupted-work Recovery 與 Bounded Concurrency
一路等待到最終 Persistence Boundary 的 Cancellation 與 Shutdown
Scoped Admission 與 Fail-closed Resume Preparation
Checkpoint-before-success Ordering 與 Isolated Hosted Invocation Contract

刻意保留在 Lucid 的 Domain Behavior

一次 Agent 與 Execution 可以看見哪些 Product Event
什麼才算有效 Finding、Response、Working-note Update 或 No-action Result
Effect 如何 Deduplicate，以及 Product Cursor 如何前進
Paused、Failed、Retryable、Waiting 與 Completed 如何呈現給使用者

已部署實證實際觀察到什麼

最強的證據不是精心設計的 Chat Demo，而是 Durable Product State、Coordinator、Managed Isolated Runtime、Scoped Tool 與 Terminal Settlement 之間可相互對應的行為。

連續兩次 Timer-due Wake 都在沒有 Check now、Foreground Chat 或開著 Browser 的情況下啟動。
兩次 Attempt 都恢復既有 Checkpoint、只檢視 Frozen Lucid Scope，並 Settlement 為 No new Finding，而不是捏造 Activity。
Scheduled Start 與 Persisted Due Time 的差距約一秒或更短。
Scoped Pause／Resume 排除了 Closed Window 期間 Commit 的 Event，只讓 Lucid Durable Resume Boundary 之後的 Event 進入新工作。
Local Fault-injection Proof 在 Preparing 中殺死 Coordinator；Replacement 使用同一 Transition 繼續，且沒有提早打開 Admission。
Ownership 轉移後，Stale Execution 無法繼續寫入或 Settlement Product Work。

選擇整合方式理解 Agent Run 管理使用獨立 Execution Host 檢查正式環境邊界

把 Capable Runtime 變成 Product-owned Delegated Work

Heddle 提供可重用的 Agent 與 Lifecycle Mechanics。你的產品仍然定義這是誰的工作、Agent 可以觀察與改變什麼，以及何時結果才在產品中成為事實。

理解 Runtime 放置方式討論產品整合