KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
03. 让 Ollama 成为一个边界清楚的专业 Agent — keel 龙骨
现在只实现一个指标分析 Agent。它不会决定团队结构，不会给自己分派新任务，也不会读取所有运行状态。它接收一个已经授权的 CollaborationTask，返回结构化 FindingArtifact。
现在只实现一个指标分析 Agent。它不会决定团队结构，不会给自己分派新任务，也不会读取所有运行状态。它接收一个已经授权的 CollaborationTask，返回结构化 FindingArtifact。
这种限制不是削弱 Agent，而是在建立可组合的专业边界。
一次调用的责任分配
flowchart LR
T[已验证 Task] --> P[构建最小 prompt]
P --> O[Ollama chat]
O --> J[JSON response]
J --> V[Pydantic 再校验]
V --> A[FindingArtifact]
A --> R[TaskResult]
模型负责从证据中提出 claim、confidence 和 limitations。程序负责：
- 任务是否真的分派给这个 Agent；
- 输入里允许出现哪些证据；
- 输出是否符合 schema；
- evidence ID 是否来自任务输入；
- 超时、错误和事件怎样记录。
用 Structured Outputs 固定输出形状
response = ollama.chat(
model=model_name,
messages=messages,
format=FindingArtifact.model_json_schema(),
options={"temperature": 0},
stream=False,
)
artifact = FindingArtifact.model_validate_json(
response.message.content
)
把 JSON Schema 传给模型只能提高格式稳定性，不能证明内容真实。返回后仍要做两类检查：
- Pydantic 校验字段、类型、枚举和范围；
- 领域校验确认 evidence ID 确实存在于输入证据中。
官方用法见 Ollama Structured Outputs。
system prompt 说明职责和边界
一个专业 Agent 的 system prompt 至少回答：
你是谁：指标证据分析员
你做什么：根据给定指标提出可验证发现
你不做什么：不查询未提供的数据，不执行命令，不决定发布或回滚
你必须怎样输出：遵循 FindingArtifact schema
证据怎样使用：每个 claim 必须引用输入中存在的 evidence_id
不确定时怎样做：降低 confidence，并写入 limitations
不要把租户身份、真实权限或数据库凭据放在 prompt 中。它们属于可信运行时上下文。
每个 Agent 只看完成任务所需的上下文
指标 Agent 的输入可以是：
{
"incident_id": "INC-001",
"evidence": [
{"evidence_id": "metric-latency", "value": "p95 由 180ms 升至 2.4s"},
{"evidence_id": "metric-pool", "value": "连接池等待数由 2 升至 84"}
]
}
它不需要：用户完整聊天历史、另一个 Agent 的 system prompt、工具凭据、未授权租户的数据，或协调者的内部状态。
上下文隔离带来三个收益：更少 token、更少无关干扰、更小的数据泄露和提示注入传播面。
Thinking 字段不是协作工件
Ollama 的 thinking-capable 模型可能返回 message.thinking。它与最终 message.content 分开。thinking 可以用于开发观察，但不能直接作为事实、长期记忆或下一个 Agent 的权威输入。
跨 Agent 传递的是通过 schema 和证据校验的 Artifact，而不是原始推理轨迹。官方字段说明见 Ollama Thinking。
运行真实模型
ollama serve
ollama pull qwen3:8b
$env:OLLAMA_MODEL = "qwen3:8b"
python courses/advanced/multi-agent-collaboration/course/project/examples/02_ollama_specialist.py
观察四件事：
- 输出是否始终能通过 schema；
- claim 是否只依赖输入证据；
- evidence ID 是否都能在输入中找到；
- 缺少关键数据时，limitations 是否反映不确定性。
然后故意把 prompt 中的输出要求删掉。即使模型仍能偶尔返回合法 JSON，也不能删除程序端校验。
检查理解
- Structured Outputs 保证了什么，没保证什么？
- 为什么不把完整 TeamRun 发给每个 Agent？
- 为什么 thinking 不适合作为 Agent 间契约？
- evidence ID 的领域校验应该由模型还是程序完成？
下一步增加 Coordinator，但保持 Worker 的边界不变。