三项服务对应组织部署的三个层面：Backend Agent Service 解决"对外运营 Agent 服务"的后台问题，Company Harness 解决"对内组织化上下文"的系统问题，FDE 驻场是两者共同的入口——先进入真实流程，再定义交付。
为有行业渠道和服务场景的客户提供 Agent 后台：管理面板、客户与订单记录、权限、日志、结算和持续运维，让客户对外运营自己的 Agent 服务。
查看详情为组织建立 C-suite 对齐的公司文件系统：目录即权限边界，Agent 即目录管理者，战略、知识与流程沉淀为可执行、可移交的上下文。
查看详情Forward Deployed Engineer 进入客户真实工作流：还原流程、标记决策点与权限边界、定义最小可交付方案，并把经验沉淀回服务系统。
查看详情你有行业渠道、客户关系和具体服务场景；我们提供稳定的 Agent 运行后台、管理面板、权限、日志、结算与持续运维。你对外运营自己的 Agent 服务，客户、订单、使用记录和运营数据沉淀进系统，而不是散落在工具里。
| 概览 | 说明 |
|---|---|
| 目标客户 | 需要把 Agent 能力接入自身业务、渠道或客户服务体系的合作客户。 |
| 客户问题 | 有行业渠道、客户关系或具体服务场景，但缺少稳定后台、Agent 运行能力、管理面板、权限、日志、结算或持续运维支持。 |
| 交付结果 | 客户基于 AIDC 后台服务对外运营自己的 Agent 服务，并把客户、订单、使用记录、服务边界和运营数据沉淀到系统中。 |
| 交付形态 | 后台服务接入、配置、运营支持、监控和持续迭代——是持续运营的服务，不是一次性交付。 |
| 客户需要投入 | 业务场景与目标客户描述、需要接入的服务模块、品牌与对外承诺边界、客户/订单/结算数据字段需求、合规与审计要求。 |
| 交付项 | 说明 |
|---|---|
| Agent 运行后台 | 承载 Agent 工作流的稳定运行环境，含模型与工具链接入。 |
| 管理面板 | 管理后台与客户、订单、服务记录能力，让运营数据有结构地沉淀。 |
| 权限·日志·监控 | 权限、日志、监控和基础运维——每个动作可追踪，每条边界可解释。 |
| 持续升级 | 模型、工具链和 Agent 工作流的持续升级，后台能力随模型迭代而不被锁死。 |
| 服务边界配置 | 面向客户行业场景的服务边界配置：Agent 能做什么、不能做什么，显式声明。 |
| 结算与看板 | 必要的结算、看板或运营数据支持，支撑客户对外运营和分成结算。 |
记录客户业务场景和服务边界：谁在用、用来做什么、对外承诺到哪里为止。
明确后台需要支持的对象：客户、订单、服务记录、权限、分成、结算或审计。
定义最小可运行后台配置——先让真实业务跑起来，再谈扩展。
上线试点并记录使用反馈，真实使用数据决定下一步迭代方向。
建立运营节奏：服务质量、故障、需求、结算和合规问题进入固定复盘流程。
把可复用能力沉淀为通用后台功能或交付 SOP，一次交付变成长期资产。
| 标准 | 含义 |
|---|---|
| 真实业务跑通 | 客户能用后台完成真实业务服务，而不是停留在演示环境。 |
| 记录可追踪 | 关键服务记录能被追踪——谁、何时、做了什么、产生了什么结果。 |
| 边界清晰 | 权限和服务边界清晰：人和 Agent 都只看到、只做职责内的事。 |
| 运营有闭环 | 运营问题能进入固定复盘和迭代流程，而不是一事一议。 |
| 能力可沉淀 | 可复用后台能力能从客户项目中沉淀出来，服务越做越厚。 |
示例场景：一家拥有行业客户渠道的服务商，希望对外提供基于 Agent 的专业服务，但不具备自建后台的工程能力。接入 Backend Agent Service 后，它在 AIDC 后台上配置自己的服务边界与品牌话术，通过管理面板维护客户与订单记录，结算与使用日志自动沉淀；AIDC 负责后台运行、监控与模型工具链升级，服务商专注于渠道与客户经营。
公司本身是一个 Harness：文件系统是内存，Agent 是进程，权限是访问控制，SOP 是可执行程序。我们为你的组织建立这套运行环境——公司从一个文件夹开始，被初始化、扩展、授权、部署和复盘。AIDC 自己就运行在这套系统上。
.
├── 01_executive/ # CEO Agent — 战略与决策
├── 02_information/ # CIO Agent — 输入与研究
├── 03_finance/ # CFO Agent — 定价与模型
├── 04_products/ # CPO Agent — 产品与服务
├── 05_technology/ # CTO Agent — 研发与部署
├── 06_operations/ # COO Agent — 交付与 SOP
├── 07_human_resources/ # CHO Agent — 角色与训练
├── 08_legal/ # CLO Agent — 合规与边界
├── 09_marketing/ # CMO Agent — 品牌与内容
└── 10_sales/ # CSO Agent — 客户与渠道| 信号 | 说明 |
|---|---|
| 上下文散落 | 战略、知识和决策散落在聊天记录与个人记忆中，新成员和 Agent 都无法接手。 |
| 权限靠默契 | 没有目录级权限边界，"所有人和所有 Agent 看到所有内容"。 |
| 交付不沉淀 | 每次项目都是一次性交付，流程没有变成 SOP，经验没有变成文件。 |
| 准备引入 Agent | 希望让 Agent 安全参与真实工作并承担明确职责，而不是停留在聊天窗口。 |
| 面临移交 | 公司需要被交给新员工、合伙人或 Agent 接管，不能再依赖某个人脑中的隐性上下文。 |
Harness 部署改变的是工作方式，不只是工具：如果团队只想采购一次性软件、不打算调整上下文与权限的组织方式，这项服务暂时不适合你。Harness 是单组织的最小运行环境；当组织需要多部门 Agent 自治协作与完整审计时，它自然演进为 AIDC 平台的完整形态。
Forward Deployed Engineer 是进入客户真实工作流的人：理解业务、拆解流程、识别 AI 部署机会、搭建或协调搭建解决方案，并把交付经验沉淀为服务资产和公司知识。AI 部署不是软件安装——客户通常说不清自己真正需要什么，需要有人进入现场抽象问题。
AI 部署需要同时理解组织、流程和权限。FDE 把客户现场的问题、业务流程、AI 能力、文件系统和 Agent 交付连接起来，并把一次性交付转化为可复用的服务、模板、SOP 和 Agent 工作流。
记录客户背景和线索来源，建立调研档案。
画出客户当前工作流，不急于提出方案。
标记人工重复步骤、决策点、数据来源和权限边界。
识别 AI 可以辅助、自动化或重构的环节。
区分 quick win、系统性改造和暂时不适合做的部分。
定义一个最小可交付方案，而不是一揽子改造计划。
记录需要客户提供的输入、系统访问和决策人。
把可复用经验写回服务交付目录，一次调研变成服务资产。
如果发现竞争力或定位判断，更新战略相关文档。
不能只记录客户说了什么，必须还原真实流程——客户的描述和实际工作流往往不是一回事。
不能只提出工具建议，必须说明组织和权限边界——工具不解决责任归属问题。
不能把一次客户需求当成通用战略，必须标记证据强度——单点样本不外推。
每次调研至少产出一个可沉淀到公司文件系统的结果——没有沉淀的调研等于没做。
以下情况 FDE 不独立决策，必须升级讨论——确保现场判断不越过服务边界、安全边界和组织边界：
| 升级触发 | 处理方式 |
|---|---|
| 超出服务边界 | 客户需求超出当前服务边界：升级讨论是否扩展服务定义，而不是现场即兴承诺。 |
| 敏感数据访问 | 需要访问敏感数据或关键系统：先明确授权方式、审计方式与责任归属，再推进。 |
| 组织结构影响 | 方案会影响客户组织结构或岗位职责：必须有客户决策人参与，不替客户做组织决定。 |
| 产品化信号 | 出现可产品化或可重复销售的信号：进入服务定义流程，沉淀为标准服务包。 |
五个阶段，每个阶段有明确产出和退出点。先调研后方案，先试点后扩展——你随时知道项目处在哪一步、下一步要交付什么。
你描述业务场景与希望改善的指标，我们判断需求是否在服务边界内，约定调研范围与参与人。此阶段不出方案、不做承诺。
FDE 进入真实工作流，按九步 SOP 还原流程、标记决策点与权限边界，产出流程调研笔记、AI 部署机会清单与风险依赖清单。
定义最小可交付方案：范围、所需输入、系统访问与决策人。先交付一个可验证的环节，而不是一揽子改造。
上线试点：配置权限、日志与监控，真实业务跑通，使用反馈被完整记录，作为迭代依据。
建立固定运营节奏：服务质量、故障、需求与合规问题进入复盘流程；可复用能力沉淀为 SOP 与通用功能，系统随使用演进。