Guga 的设计哲学是什么？它的优缺点是什么？

背后工程点：Guga 的价值不在单点功能最多，而在同一套 runtime contract 能复用到多个产品形态。
专业术语：
Runtime-first 是运行时优先；
SDK Helper 是开发辅助封装；
Runtime Contract 是运行时契约；
Product Surface 是产品界面层；
Reusable Core 是可复用核心。
为什么这样回答：先用一句话定位，再区分 SDK 和 runtime，能让面试官知道你看的是架构承重层，不是 API 便利性。
小白解析：SDK 像一套工具箱，runtime 底座更像一个车间：工具、流程、权限、记录和验收都在里面。
关联知识点：Guga README 和 core README 反复强调 provider intent -> core pipeline -> hooks -> permission -> tool -> result policy -> observation。

背后工程点：runtime-first 必须用产品面证明价值，否则会停在平台叙事。
专业术语：
Coding Agent 是面向代码任务的智能体产品；
TUI 是终端用户界面；
Product Proof 是产品场景证明；
Failure Rate 是失败率；
Recovery Cost 是恢复成本。
为什么这样回答：不回避“用户体验慢”的攻击，反而指出底座必须被产品验证，回答更诚实。
小白解析：你可以说自己造了好底盘，但最终还是要有一辆车让人开起来觉得稳。
关联知识点：OpenCode 是完整产品文档导向；Guga strategy 更像先做 runtime，再做 CLI/Web/IDE/worker 复用。

背后工程点：架构选择要匹配任务复杂度和组织需求。
专业术语：
Demo Path 是演示路径；
Fixed Workflow 是固定工作流；
Side Effect 是副作用；
Multi-surface Reuse 是多端复用；
Team Standardization 是团队标准化。
为什么这样回答：最后用适用边界收束，避免把 Guga 说成银弹。
小白解析：临时摆摊不用建商场；要长期开很多店，统一水电消防和账本就值了。
关联知识点：Anthropic 提醒复杂 agent system 要在简单方案不够时再引入；Guga 的 runtime-first 适合长任务、真工具和多产品复用。

背后工程点：小内核不是越小越好，可信根和事实源必须留在 core。
专业术语：
Trusted Core 是可信核心；
Plugin Boundary 是插件边界；
Schema Version 是契约版本；
Audit Semantics 是审计语义；
Replay Semantics 是回放语义。
为什么这样回答：这能避免把“小内核”说成口号。哪些能插件化、哪些不能插件化，是架构判断力。
小白解析：商场可以把餐厅和店铺外包，但消防系统、门禁规则和账本不能让每家店自己决定。
关联知识点：Guga core 管 contract 和 pipeline，session/artifact/context 等可以有插件实现，但权限和事件语义属于运行时边界。

背后工程点：插件生态必须先有安全和契约治理。
专业术语：
Plugin Manifest 是插件清单；
Namespace 是命名空间；
Capability Conflict 是能力冲突；
Signing 是签名；
Supply Chain 是供应链。
为什么这样回答：这能把“强插件”从愿景落到运行时安全细节。
小白解析：应用商店好用，但插件要声明权限、检查来源、避免两个插件抢同一个功能。
关联知识点：Guga 的小内核大外围路线需要 plugin host、capability registry、permission protocol 和 conformance tests 配套。

背后工程点：Guga 不是要否定主流框架，而是选择更底层的可嵌入 runtime 边界。
专业术语：
State Graph 是状态图；
Durable Execution 是持久执行；
Deep Agent 是长任务智能体；
Runtime Contract 是运行时契约；
Composition 是组合。
为什么这样回答：面试里不能只说“我们更好”。要说清楚位置和取舍。
小白解析：别人有现成房子和装修方案，Guga 更像打地基和管线；不同目标选不同工具。
关联知识点：LangGraph persistence、Deep Agents overview 和 Guga strategy 分别代表图式持久执行、长任务 harness 和可复用 runtime 平台。

背后工程点：平台能力的扩张顺序要遵守复杂度递增。
专业术语：
Product Spike 是产品尖峰验证；
Complexity Amplification 是复杂度放大；
Marketplace 是能力市场；
Supply-chain Risk 是供应链风险；
Platform Mainline 是平台主线。
为什么这样回答：这能解释“为什么不做炫功能”，同时承认市场速度压力。
小白解析：一辆车还没刹稳，就不要马上做车队自动驾驶。
关联知识点：Guga strategy 明确先 loop/tool/provider/context/session/replay，再 memory、多 Agent、ops 和生态。

背后工程点：抽象要由真实压力驱动，并用指标证明。
专业术语：
Abstraction Pressure 是抽象压力；
Single Implementation Trap 是单实现陷阱；
Glue Code 是胶水代码；
Conformance Test 是契约测试；
Product Loop 是产品闭环。
为什么这样回答：这是对 runtime-first 最大质疑的正面回应。承认风险后给判断信号，可信度更高。
小白解析：不要为了未来可能开的十家店设计复杂总部，先看第一家店每天真有什么问题。
关联知识点：Anthropic 建议先用简单组合解决真实问题，再在需要时增加复杂 agentic system。

背后工程点：架构价值必须用任务指标和运维指标验证。
专业术语：
Resume Success Rate 是恢复成功率；
Replay Coverage 是回放覆盖率；
Permission Precision 是权限拦截准确率；
MTTR 是平均恢复时间；
Operational Metric 是运维指标。
为什么这样回答：这能防止陷入“复杂就是高级”的陷阱。
小白解析：不能只说新机器更高级，要看它是不是真的少坏、好修、效率更高。
关联知识点：OpenAI tracing、agent eval、learn-agent trace analysis 都把过程指标和失败分类作为改进依据。

背后工程点：性能优化要区分必须同步的安全事实和可异步的分析数据。
专业术语：
Critical Path 是关键路径；
Async Telemetry 是异步遥测；
Append-only Store 是只追加存储；
Artifact Reference 是产物引用；
Trace Enrichment 是轨迹增强。
为什么这样回答：这不是否认开销，而是说明开销如何被工程化管理。
小白解析：收银必须实时记账，月底报表可以后台算；不能因为怕慢就不记账。
关联知识点：Guga 的 artifact preview、event refs、async eval 思路都服务于成本和可观测性的平衡。

背后工程点：企业化需要 runtime facts 加控制台和策略体系。
专业术语：
Tenant 是租户；
RBAC 是角色权限；
Data Residency 是数据驻留；
Retention Policy 是保留策略；
Incident Review 是事故复盘。
为什么这样回答：这既说明 Guga 的底座优势，也诚实指出产品和运维缺口。
小白解析：公司买系统，不只看能不能干活，还要看权限、审计、删除、成本和出事后能不能查。
关联知识点：Guga strategy 提到先让 runtime 可靠产出 event、permission、usage 和 artifact，再做企业后台。

背后工程点：平台生态的难点不是装插件，而是长期兼容和迁移。
专业术语：
Capability Negotiation 是能力协商；
Deprecation Window 是废弃窗口；
Test Matrix 是测试矩阵；
Major Version 是主版本；
Dual-read 是双读迁移。
为什么这样回答：这能体现你想到平台长期维护，而不是只会设计接口。
小白解析：手机系统升级不能让所有应用突然打不开；要有兼容期和测试。
关联知识点：Guga 的 contract-first 和 plugin-first 路线天然需要版本、迁移和 conformance 机制。

背后工程点：共享核心提高复用，也集中风险，必须用测试和发布治理限制爆炸半径。
专业术语：
Blast Radius 是故障影响面；
Property Test 是性质测试；
Feature Flag 是功能开关；
Canary Release 是灰度发布；
Fail Closed 是失败默认拒绝。
为什么这样回答：优点和缺点是一体两面。敢讲 core bug 风险，反而更像真实架构评估。
小白解析：城市主干道修得好，大家都受益；主干道出问题，也会堵很多地方，所以要谨慎施工。
关联知识点：Guga 小内核策略本身就是降低核心故障半径的方式，业务能力尽量外移到插件。

背后工程点：runtime 平台要支持渐进迁移，否则很难被真实产品采用。
专业术语：
Incremental Adoption 是渐进采用；
Strangler Pattern 是逐步替换旧系统的迁移模式；
Parallel Run 是新旧并行运行；
Migration Gate 是迁移门禁；
Compatibility Layer 是兼容层。
为什么这样回答：平台价值不能只靠新项目，真实团队往往已有 Agent loop，迁移路径是落地关键。
小白解析：旧工厂不能停工重建，应该先换仪表、再换高风险机器、最后换总控系统。
关联知识点：Guga 的 provider bridge、tool pipeline、event ledger 和 context policy 都可以分阶段接入，不必一次性吞掉整个产品。

背后工程点：底层事实源必须投影成用户可感知的产品能力。
专业术语：
Runtime Facts 是运行时事实；
Experience Projection 是体验投影；
Permission Explanation 是权限解释；
Trace Summary 是轨迹摘要；
Support Replay 是客服或工程复现。
为什么这样回答：这回应了“平台叙事离用户太远”的质疑，把架构价值翻译成体验价值。
小白解析：用户不关心汽车底盘结构，但关心刹车稳、出故障能查、维修不乱换件。
关联知识点：Guga 的 event、artifact、session 和 replay 如果只留在内部就不够，必须变成 resume、diff、解释和事故复盘体验。

背后工程点：权限体验要按风险分级，而不是简单全部询问或全部放行。
专业术语：
Risk-based Permission 是基于风险的权限；
Session Grant 是会话级授权；
Preview Diff 是执行前差异预览；
Reversible Action 是可撤销动作；
Trust Policy 是信任策略。
为什么这样回答：安全和体验的矛盾是 Agent 产品核心取舍，不能只说“安全第一”。
小白解析：助手查资料不用每次问你，但要转账、删文件、发邮件时必须让你确认。
关联知识点：Guga 的 PermissionKernel、工具管线和安全章节的 HITL 设计可以支持分级授权和可解释确认。

背后工程点：事件账本要保存可恢复事实，不等于无限保存原文。
专业术语：
Payload Minimization 是负载最小化；
Artifact Reference 是产物引用；
Redaction 是脱敏；
Delete Propagation 是删除传播；
Retention 是保留期限。
为什么这样回答：可审计和隐私不是二选一，关键在事实和 payload 分离。
小白解析：账本要记“谁在什么时候批准了什么”，不一定要把每份文件全文都复印进账本。
关联知识点：Guga artifact/event 分离、评测可观测性章节的 trace 隐私治理，以及企业化的 retention/deletion 都指向同一套治理。

背后工程点：生态要先用一方插件验证契约，再开放第三方扩展。
专业术语：
First-party Plugin 是官方插件；
Marketplace 是插件市场；
Hosted Runtime 是托管运行时；
Plugin Certification 是插件认证；
Commercial Surface 是商业化承载面。
为什么这样回答：平台商业化很容易诱导 core 变臃肿，这里把赚钱点放在治理和托管能力，而不是破坏架构。
小白解析：先开几家直营店把标准跑通，再让加盟店加入；总部不要把每个加盟店的菜单都写进公司章程。
关联知识点：Guga strategy 的 marketplace 和 enterprise ops 应该建立在稳定 plugin contract、permission 和 audit 之上。

背后工程点：平台化不仅是代码架构，也是组织边界设计。
专业术语：
Platform Ownership 是平台所有权；
Policy Baseline 是策略基线；
Self-service Extension 是自助扩展；
Release Gate 是发布门禁；
Guardrail 是护栏。
为什么这样回答：Agent runtime 一旦被多个团队复用，组织治理会决定它是否能长期运转。
小白解析：总部制定消防和收银规则，门店可以做自己的菜单，但不能私自改安全出口。
关联知识点：Guga 的 plugin、permission、eval 和 enterprise policy 需要对应组织职责，否则技术边界会被流程绕开。

背后工程点：好的底座要被产品场景反复摩擦，下一阶段重点是验证承重能力。
专业术语：
Productization Loop 是产品化闭环；
Trace Dashboard 是轨迹看板；
Eval Dashboard 是评测看板；
Scenario Selection 是场景选择；
Load-bearing Path 是承重路径。
为什么这样回答：这从评价转向行动，能显示你不仅会分析，还知道怎么推进路线图。
小白解析：先挑两个真实工地，把地基、管线、验收跑通，再说规模化复制。
关联知识点：learn-agent harness 路线和 Guga roadmap 都强调从最小闭环开始，用真实任务验证 runtime。