Use Case
关于 Agentitek
Agentitek 面向需要可部署 AI Agent 工作流的小团队，交付的是可验收工作流，而不是泛化咨询口号。
我们服务谁
- 已经有重复流程、并希望先做一版可部署交付的小团队
- 需要把业务规则和人工边界说清楚，而不是直接做一套重平台
- 更关心流程是否可 review、可维护、可迭代的业务 owner
我们交付什么
- Agent Spec 与 Workflow 设计
- 测试过的系统提示词与测试用例
- 目标平台的适配说明
- 用于 review、上线和验收的交付文档
我们不做什么
- 不会把 Agentitek 包装成完整 SaaS 平台
- 不会承诺高风险决策可完全自治处理
- 不会捏造案例、评价或指标
客户如何与我们合作
- 先做工作流诊断
- 确认范围、边界与验收标准
- 接收面向目标平台的交付包
- review 与测试后，再决定部署或下一轮迭代
可验证的公开信号
这页不编造创始人履历，而是优先展示当前网站和仓库里能公开验证的信号。
公开项目与交付资产
- 公开 GitHub 项目：github.com/RichardGitHub/agent-factory
- 公开页面已说明交付方法、质量门槛、交付样例与多类 use case。
- 仓库中可看到 Agent Spec、平台适配、测试模板和风险边界资产，而不是只有营销文案。
交付背景
- 当前公开工作重点是把重复业务流程整理成可部署、可测试、可维护的 workflow 交付包。
- 已公开覆盖客服 FAQ、邮件分流、内容发布、内部报告、线索评分等工作流场景。
- 交付范围围绕 spec、workflow、tests、platform adapter 和 user guide，而不是只卖 prompt。
为什么可信
- 公开写明“不做什么”，包括高风险自动付款、退款、合同签署和受监管最终决策。
- 公开写明质量门槛，而不是只展示“能做 AI Agent”的宽泛说法。
- 公开页面中的边界、升级规则和测试示例，能让买方判断这不是一个空壳 AI 站。
公开身份边界
当前可公开验证的最强信号是公开仓库、公开方法论页面和交付样例页面。GitHub 以外的社交身份只有在真实、持续维护时才应该补充，不能为了 E-E-A-T 硬编。
为什么是 workflow-first
很多站只卖 prompt。Agentitek 把 workflow-first 作为信任的一部分，因为买方真正接手的是流程，不是一段临时文本。
为什么不是 prompt-first
- 单段 Prompt 无法交代输入边界、异常路径、人工 review 点和验收标准。
- workflow-first 先把步骤、分支、升级条件和禁止动作写清楚，再写 prompt。
- 这样交付后，客户团队能 review、测试、维护，而不是依赖口头解释。
交付视角和开发视角的区别
- 开发视角容易直接进入代码或模型调用。
- 交付视角先问：谁输入、谁审批、哪里出错、什么情况必须升级。
- 这也是为什么 Agentitek 更像 workflow delivery service，而不是通用 AI 外包页面。
保密、NDA 与真人联系路径
关于页要解决的不只是“能做什么”，还要回答敏感材料怎么处理、如何联系到真人。
客户保密与材料处理
- 优先使用脱敏样本和最小必要材料。
- 敏感客户消息、风险判断和例外规则默认保留人工 review 边界。
- 详细处理边界公开写在 Data Handling & Privacy 页面。
NDA 与合同边界
如果项目涉及敏感样本、内部系统或受限资料，应在共享详细材料前先确认 NDA、合同条款、访问范围和脱敏要求。这里不把 NDA 当口号，而是当实际交付前置条件。
如何联系真人
- 当前公开入口是 workflow assessment 表单。
- 网站公开承诺的响应窗口是工作日 24 小时内。
- 适合把当前人工流程、目标结果、限制条件和预算带进来，再进入真人范围判断。
如果你在评估这是不是空壳站
- 先看公开 GitHub 项目。
- 再看 Delivery Method、Quality Score、Samples、Privacy 这些页面是否前后一致。
- 最后再看是否愿意把“不能做的事”和保密边界说清楚。