天工 AI 在 5 月 26 日放出了两款 Agent 专用模型——SkyClaw-v1.0 和轻量版 SkyClaw-v1.0-lite，同时开放 2–4 周免费试用。这批模型的核心卖点不是通用对话，而是针对智能体工作场景做了定向优化：百万 token 上下文窗口、复杂工具调用链、多轮任务编排、代码生成与文件编辑。换句话说，它不是拿来闲聊的，是拿来干活儿的。
为什么 Agent 模型需要单独优化
通用大模型做 Agent 时有几个硬伤：
- 上下文不够长——一个涉及多文件、多步骤的任务，中间状态和工具返回结果很容易把窗口塞满，模型还没完成任务就"失忆"了。
- 工具调用不稳定——简单的一次性调用还行，但连续调用 3–5 个工具、前后依赖参数传递时，格式错误和逻辑断裂的概率陡增。
- 多轮执行缺乏连贯性——任务拆解后每一步的执行结果需要喂回模型做下一步决策，通用模型经常在中间轮次丢失目标。
SkyClaw-v1.0 把百万 token 上下文和这些 Agent 场景绑在一起解决，思路很直接：窗口够大，中间状态不用压缩；工具调用链路专门训练，格式和逻辑更稳；多轮任务编排有针对性优化，减少中途跑偏。
两个版本怎么选
| SkyClaw-v1.0 | SkyClaw-v1.0-lite | |
|---|---|---|
| 上下文窗口 | 百万 token | 较短（具体数值待官方文档确认） |
| 适用场景 | 复杂多工具、长链路、大文件处理 | 单工具或短链路、轻量部署、低延迟 |
| 资源消耗 | 高 | 低 |
| 典型任务 | 多文件代码重构、跨系统数据流转 | 单次查询+工具调用、简单脚本生成 |
如果你的 Agent 需要同时读多个源文件、调用多个 API、再汇总写入，选 v1.0；如果只是"查一下数据库再回复用户"，lite 版够用且更快。
工具调用：从单次到链式
SkyClaw 重点优化了复杂工具调用。一个典型的链式场景：先查用户信息，再根据结果调支付接口，最后生成确认邮件。下面用一个假设的 API 接口（天工开放平台风格）演示如何构造多工具调用的请求。
注意：以下 API 路径和参数格式为合理假设，实际调用请以天工官方文档为准。替换
YOUR_API_KEY和具体工具定义后再运行。
import openai # 天工 API 兼容 OpenAI SDK 格式
client = openai.OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.tiangong.cn/v1" # 假设的端点，以官方文档为准
)
tools = [
{
"type": "function",
"function": {
"name": "query_user",
"description": "根据用户 ID 查询用户基本信息与账户余额",
"parameters": {
"type": "object",
"properties": {
"user_id": {"type": "string", "description": "用户唯一标识"}
},
"required": ["user_id"]
}
}
},
{
"type": "function",
"function": {
"name": "create_payment",
"description": "为指定用户创建一笔支付订单",
"parameters": {
"type": "object",
"properties": {
"user_id": {"type": "string"},
"amount": {"type": "number", "description": "支付金额（元）"},
"reason": {"type": "string", "description": "支付原因"}
},
"required": ["user_id", "amount", "reason"]
}
}
},
{
"type": "function",
"function": {
"name": "send_notification",
"description": "向用户发送通知邮件",
"parameters": {
"type": "object",
"properties": {
"user_id": {"type": "string"},
"subject": {"type": "string"},
"body": {"type": "string"}
},
"required": ["user_id", "subject", "body"]
}
}
}
]
# 第一轮：模型决定调用哪些工具、以什么顺序
response = client.chat.completions.create(
model="skyclaw-v1.0",
messages=[
{"role": "system", "content": "你是一个财务助理 Agent，按步骤完成用户请求。"},
{"role": "user", "content": "用户 u-8842 需要缴纳 120 元年费，请查询余额后扣款并发通知。"}
],
tools=tools,
tool_choice="auto"
)
print(response.choices[0].message)
# 预期：模型返回 tool_calls，依次调用 query_user → create_payment → send_notification
关键点在于 tool_choice="auto" 让模型自行决策调用顺序和参数传递——SkyClaw 的训练重点就是让这条链路少出错。实际部署时，你需要在每一轮把工具执行结果以 tool role 回传，模型再决定下一步，直到任务完成。
百万 token 上下文的实际用法
百万 token 不是为了炫参数，而是让 Agent 在长任务中不用反复摘要。几个真实场景：
- 多文件代码重构：把整个项目的源文件塞进上下文，模型同时理解跨文件依赖，生成的一致性远高于逐文件处理。
- 长对话 + 工具累积：客服 Agent 处理一个用户的多轮咨询，中间调了 5 次工具，所有历史和返回值都在窗口里，不会丢上下文。
- 文档审阅与编辑：把一份 200 页的合同全文放入，模型直接定位条款、提出修改、输出编辑后的文件。
下面演示一个简化版的多文件代码理解场景：
# 假设你有一个小项目的三个源文件，拼成超长 prompt
file_contents = {
"models.py": open("models.py").read(), # ~8000 tokens
"api.py": open("api.py").read(), # ~12000 tokens
"tests.py": open("tests.py").read(), # ~6000 tokens
}
combined = "\n\n".join(
f"=== {name} ===\n{content}" for name, content in file_contents.items()
)
response = client.chat.completions.create(
model="skyclaw-v1.0",
messages=[
{"role": "system", "content": "你是代码审查 Agent，基于完整项目上下文给出重构建议。"},
{"role": "user", "content": f"以下是项目源码：\n{combined}\n\n请指出 api.py 中与 models.py 不一致的类型引用，并给出修改方案。"}
],
temperature=0.2
)
print(response.choices[0].message.content)
百万 token 窗口让模型同时看到三个文件的完整内容，跨文件引用不一致的问题能被一次性抓出来，而不是靠你手动拼摘要。
上手建议与取舍
- 先跑 lite 版验证流程——如果你的 Agent 流程还在原型阶段，用 lite 版快速迭代工具定义和任务编排，确认逻辑无误后再切到 v1.0 处理长上下文。
- 免费试用期内压测边界——2–4 周窗口不长，建议优先测试你最关心的场景：多工具链式调用的准确率、超长上下文下的指令遵循度、代码生成的可运行比例。
- 工具定义要精确——Agent 模型的工具调用质量很大程度取决于你给的 function schema。参数描述越具体，模型传错参数的概率越低。不要写
"amount": {"type": "number"}，写"amount": {"type": "number", "description": "支付金额，单位为元，必须大于0"}。 - 监控中间轮次——多轮任务中，每一步的 tool 返回结果都要检查后再回传。模型不会自动纠错工具返回的异常值，你需要在应用层做校验。
- 长上下文 ≠ 无限记忆——百万 token 是窗口上限，不代表模型对窗口内所有内容的注意力均匀分布。关键指令和最近几轮对话的权重更高，重要约束建议在 system prompt 或每轮末尾重复强调。
SkyClaw-v1.0 把 Agent 场景的几个痛点打包解决了，但最终效果取决于你怎么定义工具、编排任务、校验中间结果。模型是引擎，流程设计才是方向盘。