骨架立起来之后，我盯着那个空着的角色指令文本框发了会儿呆。它看起来只是个输入框，但我后来才明白，智能体答得好不好，八成取决于这一段字，而不是取决于你选了哪个模型。

一、角色指令是命门

角色指令（Prompt）直接决定智能体的身份和行为逻辑。平台文档里也明说：它直接决定你所创造的智能体的效果。

我第一次写得很省事："你是一个乐于助人的助手。“结果它什么都敢答，答不到点上还会编——因为"乐于助人"在它看来等于"什么问题都要接”。

后来我改成三段式：定位（你是谁、服务哪类人）、能力边界（只处理什么范围，超出就明说不会）、回复风格（中文、分点、控制字数）。效果立刻不一样。尤其是那段"超出范围就明确回复不会"，加上之后它编造的次数明显下降。

写这段的经验是：别写"要 helpful"这种形容词，写可执行的规定。尤其是"不要做什么"那几句，比"要做什么"更能决定体验——因为它决定了智能体在什么情况下该闭嘴。

二、模型怎么选

模型选择只在 LLM 模式下可配。平台集成了盘古大模型，也接入了三方模型，你可以按场景挑。

我的挑法看四点：中文表达是否自然、响应速度能不能接受、成本、以及是否支持 Function Calling（要调插件或工具就得看这个，它决定了模型能不能"动手"）。

我自己的习惯是先用默认模型把链路跑通，确认是 Prompt 的问题还是模型的问题，再决定换不换。上来就换模型，很容易把两者的问题搅在一起——Prompt 写得含糊，换什么模型都不会好，而你会误以为是模型不行。

三、知识库与插件：拓展它的边界

知识库 是解决"它不懂我的业务"的手段。把产品手册、FAQ、业务文档传上去，平台做检索增强，回答就有依据，幻觉明显变少。我做问答类智能体时，这一步带来的提升比调 Prompt 还大——因为 Prompt 管的是"怎么说"，知识库管的是"说什么"，后者往往是短板。

插件 分两种：云插件的能力在云侧，访问服务接口拿内容；端插件跑在 HarmonyOS 设备侧，构建智能体与设备侧应用的通路，从应用取信息或操控应用。想让智能体"动手"而不只是"动嘴"，端插件是关键。

长期记忆和对话轮数 也能配（上下文轮数一般在 0–20 之间），它决定这个智能体能记住多少轮前文。轮数不是越高越好，调高会增加成本和延迟，够用就行。

四、自动提示词优化的坑

平台提供自动化提示词优化能力，能帮你把 Prompt 润得更规范。但我踩过一次亏：优化后的版本把我写的"超出范围就明确拒绝"那句，弱化成了"尽量帮助用户"。它让 Prompt 更顺，却把边界磨掉了。

所以我的做法是：让它优化，但优化完一定逐句核对一遍，特别是边界和拒绝规则那几句——那是最容易被"优化"掉、又最影响审核和体验的部分。工具会帮你把话写漂亮，但边界是你自己要守的东西，它不懂。

五、和"自己搭底座"有什么区别

这一点必须说清，因为它决定了你什么时候该用平台、什么时候该自己写代码。

平台内编排：在开放平台配 Prompt、挂模型、挂知识库，零代码或低代码，做完上架就被系统分发到小艺的各个入口。求的是"快"和"分发"。

自己工程里接（我前面那个系列做过）：在 DevEco 里写 ArkTS，自己接云端大模型 API，能力只在你自己的应用内生效。求的是"可控"和"深度定制"，不进小艺的分发网络。

两者不是替代关系，是分工。我现在的做法是：要被系统分发、要快速验证，用平台编排；遇到复杂定制逻辑、要复用已有业务代码、要调端侧能力，就写成 Skill 补上去（第 6、7 篇就是这两条路）。

到这一步，智能体已经能答出像样的东西了。但你会发现它只会"说"、不会"做"——因为执行层还没接上。下一篇，我们把 Skill 这个概念掰扯清楚：它到底是什么，和 Agent 怎么分工，以及为什么我一开始理解错了。