NatusAI请求与决策
对话、问题、需求、验收标准和审批各自保持独立的含义，归属清晰。
Orion工作台 · Orion内部的互联体验平台愿景
一项请求，一条可追溯的推进路径
当工作从一次对话变成任务、代码变更或部署时，其原本的含义不应丢失。Orion工作台的设计定位，是成为汇聚应用背后的人员、决策与证据的互联空间。
此处描述的体验是我们为NatusAI Orion设定的发展方向。产品范围和可用性另行认定；本页并非发布公告。
追踪工作进展
“当某批货物可能错过到港时间窗口时，请通知我们的团队。”
下面这个示例请求展示了预期的流转链条。每个阶段都会产出下一位人员或经授权的智能体可以核查的成果。
请求与验收
记录需求。明确涉及哪些货物、什么情况算作延误，以及谁可以接收这些信息。收到的反馈只有在被接受后才成为需求。
变更与证据
将确切的源代码变更与预览、测试结果以及推进上线的决定关联起来。未通过的验证同样保持可见。
发布与部署
创建不可变的发布版本，记录目标环境，并观察应用在该环境中是否满足验收检查。
结果与下一项请求
让由此产生的健康状况、支持和使用情况观测数据与该发布版本保持关联。用新的证据指导下一次改进。
示意性工作流程，并非正在运行的工作台，也不是已发布应用的演示。
跨会话保留的上下文
让原因与结果并列留存
四类记录始终相互关联，因此任何审查应用的人都能看到它为什么发生变化，而不仅仅是它发生了变化。
知识与源代码
文档、源代码引用和工程历史均有版本记录，并可追溯到责任人。计划采用基于Git的协作方式；代码托管平台尚未选定。
AI工作与证据
任务、尝试、检查点、诊断、评估和验证产物都与其涉及的输入和源代码版本相关联。
发布与环境
已合并的变更、已发布的版本和运行正常的部署是三种不同的结果，分别有各自的记录和检查。
工作台中的Auriga
AI获得所需的上下文，也遵守必须遵守的边界
一项任务应先找到相关的能力及其版本，再检索所需的模式定义、示例或证据。一处小改动不应需要加载整个代码仓库或全部对话历史。
持久化的尝试记录、取消机制、检查点和预算，让进行中的工作清晰可懂。摘要保留来源引用和时效信息，而应用知识仅对经授权的参与者可见。
精简的诊断信息和精确的差异对比，帮助人员和智能体核查结果，同时不会隐藏重要的正确性或权限信息。
继续了解
了解NatusAI Orion
了解NatusAI Auriga
了解NatusAI Gemini
