| 维度 | Coding Agent | 领域 Agent | 本文判断 |
| --- | --- | --- | --- |
| 工作目标 | 围绕代码库完成连续软件工程任务 | 围绕固定专业工作承担明确职责 | 二者不是强弱关系，而是目标不同 |
| 默认工具 | 文件系统、命令行、测试等通用工程工具 | 只暴露当前业务所需的状态读取、计划和执行工具 | 领域 Agent 的价值来自有意识的收缩 |
| 反馈来源 | 代码仓库、终端输出、测试结果 | 业务状态、审批结果、Session Log 与 Trajectory | 反馈必须贴近工作场景 |
| 权限边界 | 通常更宽，便于处理开放式工程问题 | 由 preset 和工具边界限制 | 职责越明确，越应该机械化收窄权限 |
| 主要风险 | 灵活性带来超出当前职责的行动路径 | 工具过少可能限制问题处理范围 | 边界应按业务目标设计，而不是按通用能力默认展开 |
| 适合场景 | 代码修改、测试修复、工程自动化 | 运维、审批、客服、内部流程等可定义职责的领域 | 专用 Harness 能提高稳定性和可治理性 |