设计 Agent¶
进行具体的开发之前，需要先明确：核心功能是什么，拆成哪几个子功能（workflow）与环节（node），每个环节挂哪些 skill、tool、知识库，权限如何设计。本章以「旅游攻略生成器」为例，介绍如何通过我们的devkit设计一个Agent。
3.2.1 定义核心功能¶
第一步，定义清楚Agent要解决什么问题、给谁用、做什么、不做什么、产出什么。
旅游攻略生成器的核心功能：
用户描述一次出行计划（目的地、天数、人数、预算、偏好），Agent 生成一份可直接使用的旅游攻略——含逐日行程、预算分项、天气/活动等真实信息，并标注来源。它不做酒店预订、不代付款、不生成行程外内容；信息不足处标"未获取"，不编造。
核心功能写进 config.yaml 的 metadata，会显示在 Agent 主页上。
字段详解见 config 字段
3.2.2 拆分子功能与环节¶
核心功能确定后，第二步把它拆成两层：
- 子功能（Workflow）：一段相对固定的流程，由一个或多个环节（Node）串行组成，如「意图识别」。
- 环节（Node）：流程里的一步，负责一件具体的事，如「需求解析」「审核」。Node 可复用——同一个「审核」节点能被多条 workflow 用；也可独立——不挂任何 workflow，供灵活模式让主 Agent 自己选择。
两种运行模式¶
- 功能模式：走固定 workflow，一条链按顺序跑完，适合路径确定的场景。
- 灵活模式：主 Agent 按这次需求自己组合 node（含未被 workflow 使用的 node），适合用户需求灵活变化的场景。
旅游攻略生成器的拆分¶
拆成两条 workflow：
| 子功能（Workflow） | 环节（Node，串行） |
|---|---|
| 意图识别 | 需求解析 → 意图分类与补问 → 审核 |
| 行程编排 | 信息采集 → 行程生成 → 审核（复用） |
对应五个 node：
parse_requirements（需求解析）classify_intent（意图分类与补问）review（审核，被两条 workflow 复用）collect_info（信息采集）generate_itinerary（行程生成）
创建方式：
| 命令 | 描述 | 示例 |
|---|---|---|
workflow |
进入 workflow 页 | workflow |
node |
进入 node 页 | node |
new <name> |
在当前页新建一条资源 | new intent_recognition |
资源文件的具体配置方式见：
- workflow → workflows/
.yaml - node → nodes/
/node.yaml
3.2.3 资源拆解¶
拆完后，给每个 node 拆解所需：知识库、skill、tool、prompt等资源。
- 主 Agent 有自己独有的prompt（
prompts/下的 system 和 requirements）。 - 知识库、skill、tool等都是统一定义，主Agent和node 均可使用。
- 每个 node 通过配置 node.yaml 的方式引用知识库、skill、tool 等项目级资源。
node 的 prompt 拆成三份文件，都放在 nodes/<id>/prompts/ 下，本质都是 prompt 的一部分，只是把角色、输入、完成标准分开写：
| 文件 | 作用 |
|---|---|
system.md |
角色与职责：这个 node 是谁、做什么、遵守什么 |
requirements.md |
需要收集的信息：执行前要拿到哪些输入 |
dod.md |
结束条件（Definition of Done）：满足哪些条件才算做完 |
知识库¶
攻略生成器需要三个知识库：
| 知识库 | 内容与用途 |
|---|---|
rules（规则约束） |
审核用：信息不编造、来源必标注、矛盾要打回 |
guides（攻略库） |
景点、交通、天气等真实素材，采集时用 |
templates（模板示例） |
好攻略的样式，生成时参考 |
知识库怎么建、怎么配检索 → knowledge 资源页
每个 node 的资源清单¶
| Node | skill | tool | 知识库 | system（职责） | requirements（收集信息） | dod（结束条件） |
|---|---|---|---|---|---|---|
parse_requirements |
parse |
— | — | 从用户描述中抽取目的地、天数、人数、预算、偏好，结构化输出 | 用户出行描述 | 目的地/天数/人数/预算已抽取；缺失字段标"未提供"，不猜值 |
classify_intent |
intent |
— | — | 判断本次输入是新增行程、追问细节还是修改行程 | 用户输入 + 已抽取的行程要素 | 意图已归类；信息不足时已生成补问清单 |
review |
review |
verify |
rules |
对行程内容做事实与自洽校验，输出通过或驳回 | 待审内容 + 来源标注 | 逐条给出通过/驳回；驳回项附原因与修改建议 |
collect_info |
collect |
weather_query、activity_query |
guides |
按目的地与日期采集天气、活动、交通、住宿，登记来源 | 目的地、出行日期 | 四类信息已采集；每条附来源与获取日期；缺失项标 information_gap |
generate_itinerary |
plan |
— | templates |
把素材编排成逐日行程，含预算分项与备选方案 | collect_info 的素材包 + 用户偏好 | 逐日行程已排；预算已分项；至少一个备选方案 |
资源创建方式：
| 命令 | 描述 |
|---|---|
skill |
进入 skill 页 |
tool |
进入 tool 页 |
knowledge |
进入 knowledge 页 |
进入后 new <name> 新建，如 new parse、new weather_query、new rules。
资源建好后，在 nodes/<id>/node.yaml 里声明 node 要引用哪些 tool、skill、knowledge：
各类资源的具体配置见 资源页总目录
完善主 Agent 的 prompt¶
资源确定后，写主 Agent 的 prompt（prompts/system.md）：角色、行为准则，以及「哪种需求走哪条 workflow」。主 Agent 据此在功能 / 灵活模式间选择，并在灵活模式现场组合 node。
配置修改示例：进入项目后使用 config 打开配置页，再执行 set metadata.description "旅行规划助手"；也可以直接使用 edit config set metadata.description "旅行规划助手" 修改字段。
主 Agent prompt 怎么写 → prompts 资源页
3.2.4 权限与红线设计【待修正完善】¶
权限统一在 trismind/policy.yaml 里配置，分三层：
- capability_permissions：某类操作是否允许，四态——
allow：恒定允许auto_permissions：允许，但还需叠加其它维度联合裁决（如web.read还要过network白名单）user_confirm：执行前需用户确认deny：红线，直接拒绝- network：网络访问控制，
default+deny_hosts（黑名单）+allow_hosts（白名单，按 method 控制） - mcp_policy_refs：允许被 node 引用的 MCP server 登记
攻略生成器的规则示例：
capability_permissions:
workspace.delete: deny # 禁止删除工作区文件
external.delete: deny # 禁止删除外部资源
sandbox.execute: deny # 不使用沙箱执行
workspace.write: user_confirm # 写行程产物需确认
web.read: auto_permissions # 查天气/活动，放行但叠加网络白名单
policy.yaml 字段 → policy-yaml
至此，设计 Agent 的核心流程就完成了。
下一步：
命令详解见 第 4 章 CLI 命令，资源字段见 资源页总目录