这不是产品功能公告，而是一组围绕真实工程问题展开的文章：为什么要做 QTable、AI 如何安全操作业务数据、Context 如何建立、Agent 如何执行工作，以及一个项目如何真正走向开源。
Self-hosted 真正困难的不是把容器启动起来，而是长期升级、恢复和运营。这篇结合 QTable 当前 PostgreSQL / Redis / MinIO / QTable / QTableUI Compose、Alembic、Health Check、Release Gate、ChangeSet 与 Runtime Trace，梳理系统已经具备的可运营基础，以及 Backup / Restore、Readiness、Metrics / Alerting 仍需要补齐的边界。
AI Native 不意味着所有工作流都要交给模型。这篇结合 QTable 当前 Rule / Event / Execution、ChangeSet Event Materialization、Scheduler、Worker、Run-As Permission、Retry、Rule Version、Loop Guard 与 Execution History，拆解 Agent 和 Automation 为什么应该分工。
代码公开只是第一步，真正部署的是依赖、容器镜像和发布制品。这篇结合 QTable / QTableUI 当前 CI、依赖审计、CycloneDX SBOM、Trivy、BuildKit Provenance、OCI Metadata、Image Digest 和 Full-Stack Release Gate，拆解一份源码如何变成可以被追溯和验证的发布物。
Agent 可以读表、分析任务、调用 Tool，但它不应该因为“是 AI”就获得更高权限。这篇结合 QTable 当前身份传递、Workspace / Item Permission、Row Permission、Skill Authorizer、Relation Sanitizer 和 Action Plan Apply，拆解为什么 Agent 权限只能收窄，不能放大。
同一条任务在 Grid 里是一行，在 Kanban 里是一张卡片，在 Gantt 里是一段时间条。这篇结合 QTable 当前 Record / View 模型与 QTableUI 实现，拆解业务状态和视图状态为什么必须分开，以及 Kanban 排序、Gantt 映射、实时同步应该如何围绕同一份业务事实工作。
真实 Agent 往往需要拆任务、估工期、读 Schema、生成 Gantt 再写入 Record。这篇结合 QTable 当前 Multi Tool Chain Runtime，拆解 ToolChainPlan、依赖与数据传递、Retry / Confirm / Rollback、运行时可观测性，以及当前 DAG 并行调度仍需要补齐的部分。
Agent 真正进入业务系统后，关键不是模型能记住多少，而是系统如何明确当前用户、Workspace、Table、View、Conversation 与权限边界。这篇结合 QTable 当前 Context Engine，拆解 Scope、对话压缩、Cache / Session / Snapshot，以及上下文如何注入 Agent Runtime。
AI 开始修改业务数据后，真正危险的是过期、越权或理解错误的决定变成业务事实。这篇结合 QTable 当前 Action Plan、record version、权限重校验与 ChangeSet 实现，拆解 Preview → Confirm → Apply 为什么是一条执行边界。
Agent 真正进入业务系统后，难点不是生成文字，而是理解对象、关系、权限和状态。这篇从 QTable 当前的 Field / Record / View / Relation / Permission 模型出发，讨论多维表格为什么是自然语言与可执行工作之间很实用的一层。
Airtable、Notion、飞书多维表格已经很成熟了，为什么还值得做 QTable？第一篇从这个问题出发，解释 QTable 真正想构建的是怎样的 AI Native 工作底座。
Markdown 原文保存在本仓库，外部技术社区内容将以此处作为 canonical source。
