软件研发与代码治理
- 业务触发
- 需求跨越代码搜索、修改、测试和复核，人工需要在多个工具之间搬运上下文。
- 推荐组装
- 仓库文件系统 + Shell/LSP + 计划与目标 + 会话持久化 + 可选 subagent。
- 控制重点
- 工作区写入范围、危险动作审批、测试证据和完整工具日志。
- 交付结果
- 可审阅补丁、检查结果、失败说明和可恢复会话。
成熟度判断最接近现成产品主线，适合作为首个试点。
业务应用场景
English | 中文
03BUSINESS COMPOSITIONS
先选“任务单元”，再谈企业 Agent 场景
可落地场景不是行业名称加一个聊天框。它必须有清晰输入、可执行动作、人工接管点、可检查产物和能被当前 Harness 承载的控制方式。
任务
边界明确、结果可判断、失败可接管。
组装
只提供完成任务所需的最小能力集。
证据
用日志、产物和人工复核验证，不用演示印象。
交互式场景组装器
选择一个场景，查看业务触发、推荐能力组合、控制重点、交付结果和成熟度判断。这里描述的是基于当前机制的试点组合，不是随仓库附送的行业解决方案。
场景选择方法
适合试点的任务既不能只是“回答得像不像”，也不应一开始就横跨整个部门。先找到一个可重复的任务单元，再确认 Harness 能否把模型意图、工具动作和业务证据连在一起。
| 判断问题 | 适合试点的信号 | 暂缓的信号 |
|---|---|---|
| 输入是否可界定 | 有固定材料、仓库、表单或请求类型 | 目标随着负责人临时判断不断变化 |
| 动作是否可封装 | 能变成少量只读或受控写入工具 | 依赖人工桌面操作且没有稳定接口 |
| 结果是否可检查 | 有测试、字段规则、引用或人工验收单 | 只能凭“感觉不错”评价 |
| 风险是否可分层 | 高风险动作可单独审批或禁用 | 一次调用同时包含多项不可逆操作 |
| 失败是否可接管 | 能把失败原因、上下文和产物交给人 | 失败后无法判断系统改了什么 |
01
业务流程
02
有边界的任务单元
03
已知输入
允许动作
可观察证据
04
Agent preset
审批与沙箱
05
经审核的结果
场景一：软件研发与代码治理
适用任务。 仓库问答、缺陷定位、局部修改、测试运行、依赖更新说明和变更审阅都能沿同一会话推进。文件系统、Shell、LSP、diff 呈现和会话持久化已经形成接近产品主线的组合。
试点边界。 选择一个代码库和一种变更类型，例如“修复带有稳定复现的缺陷”。初期限定工作区写入，删除、外部网络或发布动作继续由人工完成。检查结果和补丁是交付物，assistant 的总结只是索引。
验证证据。 任务是否形成可审阅 diff，相关检查是否真的运行，失败是否指出命令与原因，刷新或恢复后是否仍能看到同一工具轨迹。
场景二：知识检索与材料生产
适用任务。 内外部材料检索、政策或竞品梳理、会议资料整合和证据型报告可以组合 Web、文件系统、skill（技能）与上下文压缩。会话日志保留来源路径和多轮修订背景。
试点边界。 固定来源范围、报告结构和引用要求。对无法核实的事实明确标记；涉及内部敏感材料时，用文件访问策略和部署网络控制限制来源。最终发布仍由业务负责人审核。
验证证据。 抽样结论能否回到原始来源，引用是否支持对应命题，后续追问是否复用同一上下文而不篡改已确认事实。
场景三：受控后台操作
适用任务。 客服辅助、订单例外处理、运营配置和财务材料预检查可以通过领域工具进入 Harness。工具流水线为每个动作提供参数校验、策略、审批、执行和结果记录；客户端插件可以把 JSON 结果变成专用业务卡片。
试点边界。 从只读查询和可撤销动作开始。写入工具必须使用业务幂等键、调用方身份、明确审批文案和失败补偿；这些领域机制需要业务系统提供，Harness 不会自动创造事务语义。
验证证据。 未批准动作是否绝不执行，重复请求是否被业务接口识别，处理结果能否关联审批记录和原系统状态，异常是否进入人工接管队列。
场景四：研究分析与可重复计算
适用任务。 搜索、数据清洗、脚本计算、并行子问题和长时间等待可以分给 code runtime、workflow、后台任务与 subagent。中间文件和会话事件为分析结论提供过程证据。
试点边界。 只运行受信的模型生成脚本，设置时间、内存和工具范围，固定输入快照。动态 workflow 的 worker/vm 用于隔离 Host 事件循环，不是恶意代码安全边界；需要运行不可信代码时应换成独立进程、容器或远程执行提供方。
验证证据。 同一输入能否重现主要结果，运行参数和中间产物是否保留，失败能否定位到具体步骤，进程重启是否被正确标记为不可续跑而不是假装恢复。
场景五：企业 Agent 平台底座
适用任务。 平台团队可以用 profile、bundle、session preset 与能力 seam 为多个业务团队提供不同 Agent，再用 Web、CLI、ACP 和 SDK 接入现有系统。客户端插件图允许领域能力和设置界面随组合交付。
试点边界。 先支持两个差异明显的 Agent，证明它们共享运行主干又拥有不同工具与策略。企业租户、统一身份、配额、费用归集、插件签名和发布审批需要在 Harness 外或通过新增插件集成。
验证证据。 两套组装是否真正隔离工具，配置错误是否在加载期失败，模型与凭据能否在不重启核心进程的情况下更新，自动化入口是否遵守其公开协议范围。
不适合作为第一批试点的任务
- 无法给出完成定义，只希望 Agent “自主把业务做好”。
- 一次运行跨越多个不可逆系统，又没有幂等、审批和补偿接口。
- 需要把不可信代码当作安全隔离工作负载，却只准备使用 worker/vm。
- 价值只能用长期收入变化判断，无法建立过程指标和人工基线。
证据状态：除特别标注外，本页基于当前源码已确认。场景组合与试点建议属于应用推导，需要业务流程、领域工具和真实验收数据进一步验证。