Claude Opus 5.5 进入 Microsoft Foundry,值得关注的不只是“又多了一个模型选项”,而是它所面向的任务形态:跨代码库实现功能、调查复杂故障、归纳数百页资料,或者连续执行多步骤业务流程。这类工作无法依靠一次提示词稳定完成,真正的工程问题是如何保存进度、控制工具权限、验证中间结果,并在失败后继续执行。
长任务不是一条更长的 Prompt
单轮问答通常只关心输入和输出;长时间运行的任务还必须管理过程。以“为现有服务增加审计日志”为例,模型可能需要完成以下动作:
- 阅读目录结构、开发规范和相关模块;
- 找出所有需要记录审计事件的入口;
- 修改多个文件并补充数据库迁移;
- 运行测试,分析失败原因并继续修复;
- 汇总变更、风险和待人工确认的问题。
如果把这些要求全部塞进一个请求,任何一次网络中断、工具报错或上下文偏移都可能让任务从头再来。更可靠的方式,是将模型放进一个持久化执行循环:每一步都有明确目标,输出写入检查点,下一步只读取必要上下文。
对于知识工作也是如此。处理大量文档时,不应让模型直接“读完后给结论”,而应先建立材料清单,再逐份提取带来源的事实,随后进行交叉验证,最后才生成综合报告。这样可以降低遗漏、来源混淆和未经证实推断的风险。
把模型放进可恢复的执行框架
一个适合长任务的最小架构通常包含五个部分:
- 任务分解器:把目标拆成可独立检查的步骤;
- 上下文管理器:只加载当前步骤需要的文件、摘要和历史结果;
- 工具执行器:提供代码搜索、测试、文档读取或业务 API;
- 检查点存储:记录步骤状态、模型输出、工具结果和版本号;
- 验证与审批门:在提交代码、修改生产数据等高风险动作前暂停。
模型负责推理和生成建议,编排层负责状态与权限。不要把“是否已经完成”“下一步做什么”完全留在对话历史里,因为对话不是可靠的任务数据库。
还应给每个任务定义完成条件。例如,编码任务可以要求单元测试通过、静态检查无新增错误、变更只发生在允许目录;知识任务则可以要求每条关键结论附带材料编号,冲突信息必须单独列出。
一个可恢复的最小任务运行器
下面的示例展示如何把长任务拆成多个阶段,并在每个阶段后写入本地检查点。它默认以 dry-run 方式运行,不需要任何凭据;接入 Microsoft Foundry 时,需要根据实际部署提供的 API 或 SDK 文档调整请求地址、认证头、请求体和响应字段。示例中的 HTTP 契约只是便于改造的假设,并非对正式接口格式的声明。
将以下内容保存为 runner.py:
import argparse
import json
import os
from pathlib import Path
from urllib.request import Request, urlopen
STATE_FILE = Path('.agent-state.json')
STEPS = [
'分析目标,列出范围、假设和风险',
'制定可验证的执行计划,并标出需要人工批准的动作',
'根据已有结果生成最终交付物和验证清单',
]
def load_state(goal):
if STATE_FILE.exists():
state = json.loads(STATE_FILE.read_text(encoding='utf-8'))
if state.get('goal') != goal:
raise SystemExit('检查点属于另一个目标,请删除 .agent-state.json 后重试')
return state
return {'goal': goal, 'next_step': 0, 'outputs': []}
def save_state(state):
temp = STATE_FILE.with_suffix('.tmp')
temp.write_text(json.dumps(state, ensure_ascii=False, indent=2), encoding='utf-8')
temp.replace(STATE_FILE)
def call_model(prompt):
endpoint = os.getenv('FOUNDRY_ENDPOINT')
api_key = os.getenv('FOUNDRY_API_KEY')
deployment = os.getenv('FOUNDRY_MODEL', 'claude-opus-5-5')
if not endpoint:
return '[DRY RUN] 将发送给模型的提示词:\n' + prompt
if not api_key:
raise RuntimeError('设置 FOUNDRY_API_KEY 后才能进行实际请求')
# 假设性请求格式:请按 Foundry 中实际部署的 API/SDK 契约修改。
body = json.dumps({
'model': deployment,
'messages': [{'role': 'user', 'content': prompt}],
}).encode('utf-8')
request = Request(
endpoint,
data=body,
method='POST',
headers={
'Content-Type': 'application/json',
'Authorization': f'Bearer {api_key}',
},
)
with urlopen(request, timeout=300) as response:
result = json.loads(response.read().decode('utf-8'))
# 同样需要按实际响应结构修改。
return result.get('output_text') or json.dumps(result, ensure_ascii=False)
def main():
parser = argparse.ArgumentParser()
parser.add_argument('--goal', required=True)
args = parser.parse_args()
state = load_state(args.goal)
for index in range(state['next_step'], len(STEPS)):
previous = '\n\n'.join(state['outputs'])[-12000:]
prompt = f'''你正在执行一个可恢复的长任务。
总目标:{args.goal}
当前步骤:{STEPS[index]}
已有结果:
{previous or '暂无'}
仅完成当前步骤。明确区分事实、假设和待验证事项。不要声称执行了未提供的工具。'''
output = call_model(prompt)
state['outputs'].append(output)
state['next_step'] = index + 1
save_state(state)
print(f'已完成步骤 {index + 1}/{len(STEPS)},检查点已保存')
Path('result.md').write_text(
'\n\n---\n\n'.join(state['outputs']), encoding='utf-8'
)
print('任务完成,结果已写入 result.md')
if __name__ == '__main__':
main()
先进行本地演练:
python runner.py --goal '分析一个旧服务的审计日志改造方案'
程序会在 .agent-state.json 中保存进度。中途终止后再次运行同一条命令,会从下一个未完成步骤继续。准备连接实际部署时,可以设置环境变量:
export FOUNDRY_ENDPOINT='按实际部署填写请求地址'
export FOUNDRY_API_KEY='从安全的密钥存储注入,不要提交到 Git'
export FOUNDRY_MODEL='按实际部署名称填写'
python runner.py --goal '分析一个旧服务的审计日志改造方案'
生产环境不应直接用本地 JSON 文件充当状态数据库。可以将检查点替换为具备并发控制的数据库记录,并为每个步骤保存任务 ID、输入摘要、输出位置、重试次数、模型部署版本和审批状态。这样即使工作进程重启,也能安全恢复。
编码与知识工作需要不同的护栏
编码代理的主要风险是产生不可逆变更。建议默认只授予仓库读取权限,在独立分支或临时工作区中写文件;测试、格式化和静态检查可以自动运行,但推送分支、创建拉取请求、修改基础设施或发布生产版本应设置审批门。
知识工作更需要关注可追溯性。中间结果应保留文档标识、页码或段落位置,最终报告要区分原始事实、模型归纳与推测。涉及敏感材料时,还需确认数据区域、访问控制、日志保留和组织合规要求。
无论是哪类任务,都应限制最大步骤数、单步超时、总成本和连续重试次数。长时间运行不等于无限运行;一个无法收敛的代理,只是在更慢地消耗预算。
上线前检查清单
采用 Claude Opus 5.5 和 Microsoft Foundry 承载长任务时,可以从一个低风险、结果容易验证的流程开始,并逐步扩大权限:
- 明确任务的完成条件,而不是只写一个宽泛目标;
- 将状态保存在外部存储中,支持幂等执行和断点恢复;
- 为代码提交、生产写入、外部通知设置人工审批;
- 记录使用的模型部署、提示词版本、工具调用和验证结果;
- 对输入材料做权限过滤,避免把密钥或无关敏感数据送入模型;
- 用测试、引用核验或业务规则验证输出,而不是让模型自我确认;
- 在正式采用前核实可用区域、配额、价格、接口格式和组织合规要求。
长任务模型的价值,不在于让一次调用等待更久,而在于让复杂工作能够被拆解、观察、暂停、验证和恢复。模型能力决定推理上限,工程化的执行框架则决定它能否真正进入日常开发与知识流程。