01 / START为什么不是一个更大的聊天框？
聊天框擅长回答问题，却不擅长承载工作。真实的工作有项目、有文件、有多个并行的任务、有需要反复查看的中间产物，也有「这件事到底是谁做的、什么时候做的」这类审计需求。把这些东西都塞进一条不断滚动的消息流，最终只会得到一个越来越长的对话框。
天策的起点是相反的：先把工作台的结构搭好，再让 AI 进入这个结构。项目是容器，会话是任务，工具是能力，文件是事实。 模型负责理解与决策，程序负责状态、边界与可追溯性。
AI 应该在一个可解释的结构里工作，而不是在一个不可解释的黑盒里表演。
02 / TOOL一切能力都是工具调用
在天策里，「AI 能做什么」不是由一张功能清单定义的，而是由工具注册表定义的。每个工具都是一个独立文件夹，至少包含四样东西：
- 契约：
tool.json声明调用名、描述、运行时、输入输出方式；input.schema.json与output.schema.json定义参数与结果的形状。 - 权限：
permissions.json声明它能触碰什么；需要确认的操作会先询问，而不是先做了再说。 - 示例：
examples.json给模型看的调用范例，也是人复核工具行为的入口。 - 实现：
program/下的真实代码，以及它自己的依赖与测试。
这意味着工具可以被单独理解、单独升级、单独禁用。一个工具坏掉，不会让整个平台变成黑盒；一个工具不够好，可以换掉，而不是等下一次大版本更新。
更重要的是，工具的数量可以增长，而模型的主上下文不必同步膨胀。天策把低频工具设为动态加载：平时只注入一行目录摘要，模型真的需要时才读取完整参数。51 个工具里有 26 个这样工作。这不是省几个 token 的技巧，而是让「能力很多」和「注意力集中」不再互相矛盾。
03 / FOLDER一切对象都是文件夹
「文件夹」不是程序员的技术术语，而是普通人最熟悉的一种组织方式：能打开、能看见、能复制、能备份、能删掉、能放到另一个地方。
严格说，天策并没有把一切都摊平成文件：会话正文、分支图、审计块存放在项目库 SQLite 中，而不是散落成一堆文本。但它们的边界仍然是文件夹——项目是一个目录，工具是一个目录，主题是一个目录。文件夹负责「可打开、可备份、可迁移」，SQLite 负责「可查询、可约束、可并发」。两者一起成立，才是「没有黑盒」。
天策把项目、会话、工具、主题、角色、经验、记忆都尽量落成文件夹或文件：
- 项目：一个项目一个工作区。可以在天策的数据目录里，也可以直接指向你已有的目录；项目库
.Tiance/tiance.db跟着项目走。 - 会话：消息、运行记录、事件、附件都在项目库里；会话不是某个云端账号里的一段记录。
- 工具：一个工具一个 GUID 目录，契约、程序、依赖、测试放在一起，复制走就能用。
- 主题：一个主题包一个目录，
theme.json描述颜色、结构线、编辑器与背景。 - 记忆：全局记忆、项目记忆、会话压缩块各有明确的存储位置与注入规则。
这套选择带来的直接后果是：迁移不依赖平台，备份不依赖导出，审查不依赖管理员权限。 你不需要相信「数据在我们这里很安全」，因为数据本来就在你这里。
04 / PARALLEL多项目，多会话：并行的单位是任务
大多数 AI 工具的并行，是「开很多个窗口」。天策的并行，是「一个工作台里同时存在多个项目，每个项目里同时存在多个可独立运行的会话」。
这两个差别看起来只是界面问题，实际是架构问题。会话的生成任务由独立的任务管理器持有，HTTP/SSE 监听器只是订阅者：关掉面板、切换项目、甚至前端重载，都不会杀掉正在执行的任务。会话可以停止、恢复、分支；运行状态（空闲、运行中、异常）是持久化的，不是靠界面猜的。
因此，一个主会话可以把调研任务分派给子会话，自己继续做设计；子会话完成后回报结果。多个项目可以同时推进，而它们共享同一套前端骨架、会话区与后端服务。你不必为「另一个项目」重新学一遍界面。
05 / OBSERVABLE可观察性，是设计约束而不是附加功能
当 Agent 能读写文件、运行命令、控制桌面时，「它说了什么」远不如「它做了什么」重要。天策把可观察性当作硬约束：
- 工具调用有记录：工具名、参数、结果、耗时、所属会话，可以按会话检索与回放。
- 运行状态有落点：会话为什么停在 running、是哪一次 run 没有结算、消息序号是否连续，都能查到具体记录。
- 记忆压缩有痕迹：压缩不是后台偷偷发生的事，它会以系统消息与压缩块的形式出现，说明何时触发、压缩了什么。
- 权限先于执行：工具声明权限，会话有权限模式；需要人工确认的操作不会被「模型很坚持」绕过。
这些设计不会让演示看起来更炫，但会让长期使用变得可控。一个能被检查的系统，才值得被托付更长的任务。
06 / UNIFORM统一，是为了让复杂能力有地方安放
天策的前端有大量功能模块：项目总览、会话、文档标签、AI 面板、工具市场、主题、模型供应商、记忆、GitHub、预览器……如果每个功能都发明一套自己的布局与状态管理，系统会很快失去形状。
所以天策选择统一：同一套三栏骨架、同一套面板与状态栏、同一套工具卡片与调用记录、同一套主题 token。后端也采用同一组分层：api → services → repositories → infra，领域模型与 schema 贯穿其中。新能力不是「再写一个页面」，而是「在既有结构里增加一个工具或一个服务」。
统一不是审美偏好，而是降低复杂度的工程手段。结构稳定，能力才敢往上长。
07 / RESTRAINT克制：不做什么
一套设计哲学，只有明确「不做什么」才成立。天策的边界同样清楚：
- 不接管你的专业软件。地质绘图、CAD、Excel、Word 仍由原软件完成；天策在外层辅助、检查、生成与编辑，不要求你换工具链。
- 不把能力藏进黑盒。没有「内部魔法」：能调用的工具、能读的文件、能改的数据，都应当能被指出位置。
- 不偷偷上传。除模型 API 调用所需的内容外，项目文件与会话数据留在本地。
- 不假装全能。工具会失败，模型会判断错；系统要能显示失败、允许重试、留下证据，而不是用一段流畅的文字掩盖。
好的工作台不会替你思考，但它会让你的思考有地方落地，也让你的操作有据可查。
— Tiance · 设计哲学 · v0.3.39