Appearance
Symbol Index
固定源码版本：a9f633e09d49a85829b8236331b9e21f7e612634。
| Knowledge | Source Block | File | Symbol |
|---|---|---|---|
| Run、Session 和 Durable State 到底各保存什么 | Durable state 会按恢复职责拆成多个持久文件 | source/host/durable-file-policy.ts | SAND_UPGRADE_RESUME_FILE_NAME → SAND_PENDING_WAKE_FILE_NAME → SAND_XUSER_TURN_DEDUPE_FILE_NAME |
| MCP 谁可以调用什么：Authorization、OAuth 与 Enterprise Managed Auth | MCP Auth 为什么需要 Durable-ish Wait Identity | source/host/mcp-auth/mcp-auth-wait-registry.tssource/host/mcp-auth/host-mcp-auth-completion.ts | McpAuthWaitRegistry.register() / take() / prune()registerConnectCard() / resolve() / resolveDesktop() |
| Container 为什么不是完整 Sandbox：Resource、Credential 与 Security Boundary | 认证完成状态与 Agent Resume 分离 | source/host/mcp-auth/mcp-auth-wait-registry.tssource/host/mcp-auth/host-mcp-auth-completion.ts | McpAuthWaitRegistry.register() → take() → prune()HostMcpAuthCompletion.resolve() → resumeAfterMcpAuth() |
| 恢复、重试和人工审批怎样共享同一执行事实 | Approval Gate 与 Checkpoint Boundary 必须共同参与 Resume | source/host/runner/auto-review-gate.ts | assertNoPendingApproval() → shellApprovalState() |
| 历史执行怎样重放和分叉：Replay、Determinism、Fork 与 Time Travel | Approval identity 让“同一次副作用”有可验证身份 | source/host/runner/auto-review-gate.ts | shellApprovalState() |
| Human Control 如何跨进程工作：HITL、Interrupt、Approval 与 Resume | Pending Approval 是 Runtime Gate，不是 Prompt 建议 | source/host/runner/auto-review-gate.ts | createAutoReviewGate() → assertNoPendingApproval() → shellApprovalState() |
| Tool 失败后能不能重试：Retry Eligibility 与 Idempotency Contract | Side Effect identity 必须跨审批/执行可关联 | source/host/runner/auto-review-gate.ts | shellApprovalState() → getIdentity() → markSideEffectStart() |
| 重试怎样避免放大故障：Backoff、Retry Budget 与 Idempotency | 副作用 generation identity 是 Retry/Resume 的锚点之一 | source/host/runner/auto-review-gate.ts | shellApprovalState() |
| 高风险 Tool 怎样只拿最小权限：Risk、Least Privilege 与 Approval | 真正的 side-effect gate 在 Runtime Controller | source/host/runner/auto-review-gate.ts | assertNoPendingApproval() → currentModes() |
| 如何隔离 Provider 差异：Streaming、Adapter 与 Capability | Provider delta 先规范化，再进入 Runtime 事件模型 | source/host/runner/conversation-state.ts | sanitizeFullStream() → sanitizeStreamResult() → createSandResolvedModelTracker() |
| Sandbox 该隔离什么：Process、Filesystem 与 Network | 读取外部执行产物也要经过 Capability Scope | source/host/runner/shell-terminal-watch.ts | createShellWatchReadAccessor() / pollShellTerminalFile() / SandLocalToolPermissionDeniedError |
| 代码修改如何成为可验证动作：Shell、Patch 与 Command Lifecycle | 长命令如何在重连后继续被观察 | source/host/runner/shell-terminal-watch.ts | pollShellTerminalFile() → readShellTerminalSnapshot() → settle() |
| Context 如何组装：Assembly Pipeline 与 Token Budget | Context Assembly 不是拼字符串，而是 Runtime Projection | source/host/runner/system-prompt-assembly.ts | createSystemPromptAssembly() → getSystemPrompt() → getMemorySection() |
| 什么值得长期记住：Long-Term Memory 的写入与检索 | Memory 写入是 opportunistic maintenance，不是 Turn commit | source/host/runner/turn-memory.ts | runTurnMemory() → runMemoryExtraction() |
| 哪些信息能用于恢复：Memory、RAG、Event Log 与 Crash Recovery | 恢复正确性依赖 Checkpoint；Memory 维护失败不能改变 Turn 结果 | source/host/runner/turn-memory.ts | runTurnMemory() → runMemoryExtraction() |
| 运行中的并发怎么收住：Concurrency Limit、Cancellation 与 Deadline | Await/Tool Observation 必须感知 cancel/interruption | source/host/runner/turn-observation.ts | observeAwaitToolCall() → flushPendingAwaitsOnUnwind() |
| 一次 Run 的时间预算怎么传下去：Timeout、Deadline 与 Retry 分类 | MCP stall 使用独立 expiry policy 做诊断 | source/host/runner/turn-observation.ts | beginMcpExecObservation() → MCP_EXEC_STALL_THRESHOLD_MS |
| 长 Run 什么时候必须停：Long-running Execution 与 Termination | Observation owner 会枚举 subagent / shell / cloud-agent 后台任务 | source/host/runner/turn-observation.ts | listAsyncTasks() → emitAsyncTasksChanged() |
| Graph 怎样被调度并持久化：Scheduler、State Machine 与 StateStore | Observation 是 StateMachine 的输入事实之一 | source/host/runner/turn-observation.ts | turnStarted() → toolStarted() → toolCompleted() |
| 跨进程继续代码任务：Sandbox Session、Snapshot 与 Resume | Restart 后后台 Shell 可以作为 reattached task 被重新观察 | source/host/runner/turn-observation.ts | listAsyncTasks() → shellRewatchEntries() |
| 一次 Tool 批次如何安全执行：Parallel Call、Error 与 Timeout | Stall Observation 不等于 Retry Decision | source/host/runner/turn-observation.ts | beginMcpExecObservation() |
| MCP 进入生产环境后的边界：Tracing、Migration 与 Security | Tool Call 使用稳定 ID 承接跨层诊断 | source/host/runner/turn-observation.ts | beginMcpExecObservation() |
| 一次 Run 如何被推进：Lifecycle、State Machine 与 Node Transition | Tool 生命周期先变成 Runtime Fact | source/host/runner/turn-observation.ts | createTurnObservation() → turnStarted() → toolStarted() → toolCompleted() |
| 如何看见 Agent 在做什么：Logs、Metrics 与 Trace | Turn Observation 同时产出生命周期事件和性能事件 | source/host/runner/turn-observation.ts | createTurnObservation() → armDispatchObservation() → observeFirstToken() |
| Coding Agent 的工作环境是什么：Workspace 与 Filesystem State | Turn Context 同时持有 shell-watch / resource owner | source/host/runner/turn-run-shell.ts | createTurnAgentRunContext() → shellWatchHost |
| Multi-Agent 为什么容易失控：Context Isolation 与 Planning Failure | Turn Scope 在 Runtime 创建时就已经被约束 | source/host/runner/turn-run-shell.ts | createTurnAgentRunContext() → TurnAgentScope → toolSession |
| 一次 Run 如何被推进：Lifecycle、State Machine 与 Node Transition | Turn 开始前先构造 Runtime-owned Context | source/host/runner/turn-run-shell.ts | createTurnAgentRunContext() |
| Shadow Harness 从哪些边界开始：Architecture、Domain Model 与 Model Adapter | 真实工程把 Turn Context / Observation / Settlement 拆成不同 owner | source/host/runner/turn-run-shell.ts | createTurnAgentRunContext() |
| 运行中的信息放哪里：Conversation、Checkpoint 与 Short-Term Memory | Checkpoint 与 Transcript 是相邻但不同的持久化事实 | source/host/runner/turn-settle.ts | persistCheckpoint() → prepareCheckpoint() → commitCheckpoint() |
| 局部失败如何传播：Partial Failure 与 Runtime Invariants | Checkpoint 写入本身也有 invariant 和失败窗口 | source/host/runner/turn-settle.ts | persistCheckpoint() → TranscriptAppendAfterCheckpointError |
| Run 怎样安全暂停再继续：Pause、Checkpoint 与 Pending Writes | Checkpoint 是 prepare → persist → commit 的恢复边界 | source/host/runner/turn-settle.ts | persistCheckpoint() → persistStepCheckpoint() → persistFinalState() |
| Coding Agent 如何形成闭环：Planner / Generator / Evaluator、Recovery 与 Artifact Contract | Turn settle 把完成事实、Checkpoint 与后处理分开 | source/host/runner/turn-settle.ts | settleCompletedTurn() → persistFinalState() |
| Runtime 怎么做确定性验证：Unit、Contract、Fault Injection 与 Invariant Tests | 最值得故障注入的地方：Checkpoint 已写、Transcript 未 commit | source/host/runner/turn-settle.ts | persistCheckpoint() → TranscriptAppendAfterCheckpointError |
| 恢复逻辑如何防回归：Replay / Resume Tests 与 Golden Trace | 真实持久化链天然暴露 Crash Window | source/host/runner/turn-settle.ts | prepareCheckpoint() → handleCheckpoint() → commitCheckpoint() |
| 模型调用失败后怎么处理：Error Taxonomy、Routing 与 Fallback | Router 的职责边界：选择 Provider + 串行化 Agent Turn | source/node-agent-coordinator/inference-router.ts | createCoordinatorInferenceRouter() → dispatch() → execute() |
| 常见编排模式怎么选：Router、Fan-out、Manager 与 Handoff | 真实 Router 同时处理 provider 差异和 Turn 顺序 | source/node-agent-coordinator/inference-router.ts | createCoordinatorInferenceRouter() → dispatch() → execute() → queues |
| 让模型稳定调用 Tool：Schema、Examples 与 Registry | Discovery 后先形成稳定 Registry，再允许 Call | source/node-agent-coordinator/routed-mcp-bridge.ts | tools/list branch → tools Map → tools/call branch |
| MCP 如何接入现有 Harness：Gateway、Conformance 与 Adapter | MCP Bridge 不拥有业务执行，只做协议适配 | source/node-agent-coordinator/routed-mcp-bridge.ts | createRoutedMcpBridge() → tools/list branch → tools/call branch → mcpResult() |
| MCP 如何发现能力：Self-describing Request、Discovery 与 Tools | MCP Discovery 如何投影到 Harness Tool Registry | source/node-agent-coordinator/routed-mcp-bridge.ts | tools/list branch → tools Map |
| 外部能力适配：MCP 与 Workspace / Sandbox | MCP 只做 Internal Tool ↔ Protocol 的转换 | source/node-agent-coordinator/routed-mcp-bridge.ts | createRoutedMcpBridge() → tools/list branch → tools/call branch |
| 不可信输入怎样限制权限：Tool Result、Permission 与 Capability Security | Result Adapter 只转换数据形状，不授予 capability | source/node-agent-coordinator/routed-mcp-bridge.ts | mcpResult() |
| 从发现 Tool 到可回灌结果：Search、Execution、Normalization 与 Result Budget | Result Normalization 是单独的 Adapter 边界 | source/node-agent-coordinator/routed-mcp-bridge.ts | mcpResult() |
| 高风险 Tool 怎样只拿最小权限：Risk、Least Privilege 与 Approval | Risk Hint 和 Enforcement 必须分开 | source/node-agent-coordinator/routed-mcp-bridge.ts | isReadOnly() → annotations |
| 从发现 Tool 到可回灌结果：Search、Execution、Normalization 与 Result Budget | Tool Call 如何从协议层进入内部 Executor | source/node-agent-coordinator/routed-mcp-bridge.ts | tools/call branch → deps.callTool() → mcpResult() |
| Tool 如何撑爆 Context：Definition Cost 与 Result Management | Tool Definition 本身就是模型 Context | source/node-agent-coordinator/routed-mcp-bridge.ts | createRoutedMcpBridge() → tools/list branch → isReadOnly() |
| Tool 如何撑爆 Context：Definition Cost 与 Result Management | Tool Result 先归一化，再决定如何进入下一轮 | source/node-agent-coordinator/routed-mcp-bridge.ts | mcpResult() → tools/call branch |
| Tool 太多时怎么暴露：Metadata、Dynamic Exposure 与 Discovery | Tool metadata 能提示风险，但不执行权限 | source/node-agent-coordinator/routed-mcp-bridge.ts | isReadOnly() → tools/list branch |
| 模型计划如何变成真实执行：ToolExecutor、Planner 与 GraphCompiler | 内部 Tool Executor 不应依赖 MCP request 类型 | source/node-agent-coordinator/routed-mcp-bridge.ts | tools/call branch → deps.callTool() |
| 什么才是好 Tool：Contract、Granularity 与 Naming | 协议 Tool 只是内部能力的投影 | source/node-agent-coordinator/routed-mcp-bridge.ts | Tool → tools/list branch |
本地定位
bash
rg -n "<SymbolName>" <file>