很多团队已经习惯让 AI 补下一行代码、生成方法骨架或解释一个函数，但这些能力主要减少的是敲键盘的时间。SolonCode 所强调的方向更进一步：Coding Agent 不应只参与编码片段，而要围绕一个工程任务持续工作，直到产出可验证、可审查、可交接的结果。
这不是把补全窗口做得更大，而是把 AI 的工作单位从“代码片段”改成“任务交付”。
补全结束的地方，往往才是任务真正开始的地方
一个看似简单的需求，例如“给订单查询接口增加状态筛选”，通常包含一串隐含工作：
- 找到路由、服务层、数据访问层和相关类型定义；
- 判断参数是否合法以及空值如何处理；
- 修改查询逻辑，同时避免破坏现有调用；
- 增加单元测试或集成测试；
- 运行格式检查、静态分析和测试；
- 汇总修改内容、验证结果与残留风险。
智能补全擅长根据光标附近的上下文预测代码，却不会天然承担这条链路。数字员工式的 Coding Agent 则需要理解任务目标，操作代码库和工具，并根据测试结果继续修正，而不是生成一段看起来合理的代码后就停止。
两者可以用交付边界区分：
| 维度 | 智能补全 | 数字员工式 Agent |
|---|---|---|
| 输入 | 当前文件、光标附近代码 | 任务说明、仓库、规范和工具权限 |
| 输出 | 一段候选代码 | 修改集、测试结果和交接说明 |
| 工作周期 | 秒级、单轮 | 多步骤、可持续迭代 |
| 成功标准 | 代码是否像样 | 验收条件是否满足 |
| 失败处理 | 由开发者接手 | 读取错误、定位原因并再次执行 |
因此，评价 Coding Agent 时，只看代码生成速度很容易看偏。更有意义的指标是任务完成率、人工接管次数、验证覆盖率，以及最终修改是否容易审查。
“能自己写”不等于“可以放心交付”
要成为数字员工，Agent 至少需要四类工程能力。
上下文获取：它必须能搜索仓库、读取项目规范、识别构建系统，并找到与任务相关的测试。把整个仓库一次性塞进提示词既昂贵，也会引入噪声；更可靠的方式是让 Agent 按需检索和逐步收窄范围。
工具执行：修改代码只是其中一步。Agent 还需要运行测试、格式化工具、类型检查器和版本控制命令，并正确解释退出码与错误输出。
闭环验证：一次生成很少等于一次成功。有效的工作流应是“修改、执行、观察、修正”，直到验收条件通过，或明确报告无法继续的阻塞项。
边界控制：数字员工并不意味着无限权限。删除文件、访问生产环境、修改依赖锁文件、执行数据库迁移等操作，需要单独授权或人工确认。权限越大，审计和隔离要求也越高。
这也意味着任务描述必须从一句自然语言升级为可执行契约。“优化这个接口”几乎无法验收；“P95 延迟不高于 200ms，响应结构不变，现有测试全部通过”才给了 Agent 明确终点。
可以这样实践：给 Agent 一份可验收的任务单
下面不是 SolonCode 的特定接口，而是一套可以接入任意 Coding Agent 的最小任务契约。将它保存为 task.yaml，再让 Agent 或外层编排器读取。
id: order-status-filter
objective: 为 GET /orders 增加可选的 status 查询参数
scope:
allow:
- src/orders/**
- tests/orders/**
deny:
- migrations/**
- deploy/**
acceptance:
- 不传 status 时保持现有行为
- status 仅允许 pending、paid、cancelled
- 非法 status 返回 HTTP 400
- 新增有效值和非法值测试
verification:
- python -m pytest tests/orders -q
- python -m ruff check src/orders tests/orders
permissions:
network: false
write_outside_scope: false
destructive_commands: require_approval
handoff:
include_diff_summary: true
include_test_output: true
include_remaining_risks: true
如果现有 Agent 只接受自然语言提示词，可以把任务契约转换成下面这种工作指令：
你正在处理 task.yaml 中定义的任务。
工作规则：
1. 先阅读任务范围、项目规范和相关测试，再修改代码。
2. 只允许修改 scope.allow 中的文件，不得触碰 scope.deny。
3. 每次修改后运行 verification 中的命令。
4. 若验证失败，读取错误并继续修复；最多尝试 3 轮。
5. 不要绕过或删除失败的测试。
6. 完成后输出：修改摘要、验证命令及结果、未解决风险。
7. 遇到需要网络、迁移或破坏性命令的情况时停止并请求批准。
还可以在仓库中增加一个统一验证脚本，让人和 Agent 使用完全相同的交付门槛。运行前根据项目实际情况调整测试路径和工具名称：
#!/usr/bin/env bash
set -euo pipefail
python -m ruff check src/orders tests/orders
python -m pytest tests/orders -q
git diff --check
echo "Verification passed"
将脚本保存为 scripts/verify-order-task.sh 后执行：
chmod +x scripts/verify-order-task.sh
./scripts/verify-order-task.sh
这里最关键的并不是 YAML 格式，而是三个约束同时存在：明确允许修改什么、明确用什么命令验收、明确哪些操作必须停下来找人。缺少任何一个，Agent 都可能产出大量代码，却仍把收尾工作留给工程师。
引入时先挑闭环清晰的任务
数字员工式 Coding Agent 更适合从边界明确、反馈快速的任务开始，例如补充测试、修复可稳定复现的缺陷、执行小范围 API 改造，或处理规则固定的依赖升级。跨多个仓库的架构调整、缺少验收标准的性能优化，以及直接操作生产环境的任务，不适合作为第一批试点。
落地时可以检查以下几项：
- 任务是否有机器可执行的验收命令；
- Agent 是否只能访问完成任务所需的最小权限；
- 每次命令执行和文件修改是否留有审计记录；
- 失败时是否会报告阻塞原因，而不是隐藏错误或降低测试标准；
- 最终输出是否包含修改摘要、验证证据和剩余风险；
- 团队是否统计人工接管率与返工率，而不只统计生成代码行数。
从智能补全走向数字员工，真正的变化不是 AI 写了更多代码，而是它开始承担代码之外的工程责任。只有当任务范围、工具权限、验证循环和人工审批共同建立起来，Coding Agent 才可能减少交付成本，而不只是把代码生成得更快。