问题证据
事件、流程、代价
找到一个真实发生过的任务，画清谁发现、谁判断、谁执行、谁审批，以及延迟、返工、人工小时和风险暴露。
第 0 层 · 问题与结果
先别从模型开始，先确认问题真的发生过。
客户说“想要一个 AI 客服”，不等于客服自动化就是正确项目。先追问最近一次怎么发生、谁参与、花了多少时间、错了会付出什么代价，以及谁愿意提供数据和负责验收。
结果定义
不要只数功能
“接入 20 个工具”“回答准确率 92%”不等于成功。应说明解决率、响应时间、人工成本或风险事件要怎样变化。
结果树：业务结果 → 用户行为 → 智能体行为 → 工程指标。工程指标用来解释结果，不能替代结果。
我会逐项问这七个问题
从一件具体工作，看它能不能长期交给系统。
不是每个项目都需要同样复杂的建设。但下面七件事，只要有一件说不清，先别急着扩大范围。
谁在请求？它能做什么？
请求必须绑定用户、Agent、服务账号、组织和租户。RBAC 负责职责，ABAC 负责动态条件，关系权限负责资源归属；权限还要在数据和工具层再次检查。
依据从哪里来？能否追溯？
文档要有来源、所有者、版本、时效、密级和删除规则。检索索引必须继承原文权限，记忆、缓存、日志和临时文件也不能成为越权后门。
模型提出什么行动提案？
自然语言不能直接进入高风险工具。让模型输出结构化意图、目标资源、动作、参数、理由、置信度和风险级别，再经过 schema 与策略检查。
动作能否暂停、验证和回滚？
工具需要最小权限、输入输出 schema、幂等、超时、限流、事务边界和审计。付款、发信、删数据、改生产配置等不可逆动作应有审批或人工确认。
失败时会发生什么？
准备超时、重试、熔断、限步、备用模型、人工降级、检查点、断点续跑和成本预算。多活不是默认答案，先分清会话状态、任务状态和外部副作用。
出了问题能还原现场吗？
关联记录用户、模型、Prompt、策略、上下文、检索文档、工具参数、授权结果、人工干预、成本和延迟。评测要覆盖越权、误操作、恢复和业务结果。
上线以后，谁真正拥有它？
业务团队要拥有业务结果，平台团队提供身份、策略、检索、评测和运行能力。交付时还要写清谁更新知识、维护策略、处理事故、批准变更，以及顾问何时退出。
最容易被忽略的分界
把控制面和数据面分开。
控制面决定身份、策略、模型路由、工具目录、审批、预算、审计和发布；数据面负责具体检索、推理、任务执行和业务读写。业务 Agent 可以快速迭代，但不能自行修改控制面。
任何权限、策略、生产工具和模型路由的改变，都应该经过受控发布。这让“能自我行动的软件”拥有清楚的边界。
控制面
身份 · 策略 · 版本 · 审批 · 审计 · 预算
数据面
检索 · 推理 · 工具调用 · 业务数据读写 · 结果验证
模型输出应是受约束的行动提案，不是未经检查的最终事实。
从判断到执行
别只看演示顺不顺，要看出错后怎么收场。
接收
确认任务和上下文
→
判断
提出下一步动作
→
核对
检查权限和风险
执行
调用工具并留记录
→
复核
确认动作和结果
→
接手
必要时交给人处理
输入 → 意图 → 核对 → 工具 → 结果 → 记录 → 反馈
企业交付的最小单元
它需要成为一个边界清楚、有人负责的业务执行单元。
它应该有明确的目标、输入、可访问数据、可用工具、决策规则、审批条件、服务目标、责任人和回滚方案。项目第一步不是选模型，而是画业务流程、识别决策点和责任边界。
资料整理、分类、摘要、初稿。
合同问题清单、客服回复、对账异常。
付款、删除、对外承诺和生产变更。
从真实项目开始
先证明“可控地创造价值”，再扩展到更多 Agent。
Soloharness 可以和你一起盘点一个真实流程：问题证据、业务结果、数据权限、工具边界、人工审核、评测方式和长期 owner。先做一个成本可控、可回退的验证，再决定是培训、陪跑、定制建设还是长期运营。
了解合作方式带来这三样就够了
- 一件真实工作：最近反复发生、有人正在处理。
- 一份脱敏材料：样本、记录、规则或现有流程。
- 一个业务 owner：能判断结果是否有用、风险是否可接受。