Coding Agent Runtime 行为研究报告
工具暴露、上下文注入与 DeepSeek V4 Pro Harness 适配实验
Coding Agent Runtime 行为研究报告
——工具暴露、上下文注入与 DeepSeek V4 Pro Harness 适配实验
一、研究背景
模型能力本身已经不再是唯一决定因素。 同一个模型，在不同 Agent Harness（运行框架）中，可能表现出完全不同的行为模式。 本研究起因于一个实际观察：
在 Pi Agent 中使用 DeepSeek V4 Pro 时，社区中常见的一个现象被复现：
- 某些环境下，模型更像工程 Agent：
- 快速进入任务
- 主动读取代码
- 修改并验证
- 常以 “We need…” 等执行型语言开头
- 某些环境下，模型更像传统聊天助手：
- 先解释任务
- 先描述计划
- 出现 “Let me…” 等分析型开头
- 首次行动更慢
最初的问题：
为什么同一个模型，在不同 Harness 中表现不同？
研究目标：
- 判断影响因素来自：
- System Prompt？
- Extension？
- Tool 暴露？
- Tool Description？
- Subagent Context？
- 找出适合 DeepSeek V4 Pro 的 Pi Agent 架构。
二、核心假设
初始假设：
假设 1：Prompt 决定 Agent 行为
认为：
通过调整：
- APPEND_SYSTEM.md
- AGENTS.md
可以让 Pi 接近 DeepSeek Harness。
实验后发现：
部分正确，但不是主要因素。
假设 2：Subagent Extension 导致行为变化
认为：
加载 subagent-orchestrator 后，额外代码和上下文污染模型。
实验后：
错误。
因为：
即使加载 extension，但隐藏 delegate_task 后，模型恢复正常。
假设 3：Tool Exposure 改变模型行为
最终被验证。
即：
模型看到某个高级工具存在，本身就会改变 reasoning path。
三、实验方法
采用控制变量实验（A/B Testing）。
核心原则：
一次只改变一个变量。
统一测试任务：
阅读当前项目代码，分析启动流程中的潜在问题，并提出修复方案。如果需要修改，请执行修复并验证。
观察指标：
- 首响应风格：
- We need
- Let me
- 行为模式：
- 是否直接进入代码分析
- 是否执行修改
- 是否验证
- 工具行为：
- 是否调用 delegation
- 是否出现 agent orchestration 讨论
四、实验一：APPEND_SYSTEM 影响测试
环境 A
配置：
- Pi 原生
- 无 Extension
- 无 APPEND_SYSTEM
结果：
模型：
- 能进入 coding workflow
- 偏向 We need
- 但倾向等待用户确认后执行
环境 B
配置：
- Pi 原生
- APPEND_SYSTEM
内容：
简单的软件工程 Agent 身份描述。
结果：
模型：
- We need
- 输出计划后直接执行
结论
APPEND_SYSTEM 主要影响：
执行授权感
而不是：
推理风格本身
简单的 Agent Identity 可以让模型更像执行型 Agent。
但不是主要决定因素。
五、实验二：subagent-orchestrator 影响测试
加入：
subagent-orchestrator。
结果：
DeepSeek V4 Pro 出现：
- Let me 开头增加
- 初始决策变慢
提出三个可能原因：
- Extension 本身
- delegate_task description
- delegate_task tool 暴露
六、实验三：delegate_task 工具暴露实验
实验 A
配置：
- 加载 subagent-orchestrator
- 删除 delegate_task tool 注册
结果：
恢复 baseline。
表现：
- We need
- 正常 coding workflow
说明：
不是 extension 本身。
实验 B
配置：
- 保留 delegate_task
- 简化 description
结果：
仍出现：
- Let me
说明：
不是 description 长度问题。
结论
关键因素：
不是：
subagent extension
不是：
tool description
而是：
delegate_task 是否进入模型默认 tool space
七、核心发现：Tool 是 Context
传统理解：
工具：
给模型增加能力。
实验发现：
工具同时也是：
给模型增加决策空间。
当模型看到：
Available tools:
read
bash
edit
delegate_task
它不仅知道：
“我可以调用子 agent。”
同时会考虑：
- 是否需要委派？
- 是否应该拆任务？
- 是否调用 reviewer？
- 是否自己执行？
因此：
工具暴露改变了模型行为分布。
八、实验四：Command Delegation 架构验证
目标：
保留 subagent 能力，但不污染默认 coding 模式。
方案：
从：
Model
|
| tool call
|
delegate_task
改为：
User
|
/delegate command
|
Pi runtime
|
subagent
|
result injection
|
Main Agent
实验结果：
expC：
默认：
工具：
read
bash
edit
write
无：
delegate_task
结果：
DeepSeek V4 Pro：
- 恢复 We need
- 正常执行
- 速度无明显下降
同时：
用户执行：
/delegate explorer xxx
仍然可以：
- 启动子 agent
- 获取结果
- 注入主 session
九、实验五：Subagent Result Injection 测试
问题：
虽然 tool 不暴露，
但是：
子 agent 返回结果是否会污染上下文？
测试流程：
-
普通 coding task
-
/delegate explorer
-
继续任务
结果：
注入前：
We need
注入后：
- 无 Let me
- 无 agent 状态讨论
- 无明显速度下降
- 正常修改代码并验证
当前结论：
Tool Exposure：
高影响。
Result Injection：
当前格式：
低影响。
十、当前架构结论
不推荐：
Main Agent
+
所有能力默认暴露
+
delegate_task tool
+
multi-agent orchestration
因为：
强模型可能被迫考虑过多决策。
推荐：
默认模式
DeepSeek V4 Pro
Tools:
read
bash
edit
write
目标：
保持 minimal coding agent。
高级模式
显式触发：
/delegate
流程：
Main Agent
|
|
Subagent Worker
|
|
Result Injection
|
|
Main Agent Continue
十一、对 Agent Harness 设计的启示
1. 更多工具 ≠ 更强 Agent
能力增加可能带来：
- 决策空间增加
- reasoning overhead 增加
- 行为漂移
2. Tool List 本身就是 Prompt
模型看到的工具集合，会影响：
- 任务理解
- 规划方式
- 执行策略
3. 高级能力应该按需激活
成熟 Harness 不应该：
默认展示所有能力。
而应该：
根据任务需要提供能力。
十二、未来研究方向
1. Router Agent
研究：
如何自动判断：
普通任务：
单 Agent
复杂任务：
开启 delegation
2. Result Injection Engineering
进一步测试：
不同结果格式：
A:
Explorer findings:
...
B:
Agent completed:
...
C:
Recommendation:
...
是否影响模型行为。
3. Agent Evaluation
建立量化指标：
- 修复成功率
- Token 消耗
- 工具调用次数
- 首响应时间
- 回滚率
- 长任务稳定性
十三、最终总结
本研究没有证明：
“DeepSeek V4 Pro 只能适配官方 Harness”。
更准确的结论：
强 Agent 模型的表现高度依赖运行环境。
模型能力只是基础。
最终行为由：
Model
+
System Context
+
Tool Exposure
+
Tool Result
+
Execution Loop
共同决定。
对于当前 DeepSeek V4 Pro + Pi：
最佳实践不是让 Agent 拥有最多能力。
而是：
保持默认环境简单。
让高级能力在真正需要时被激活。
这也是未来 Coding Agent Harness 设计的重要方向。