从 gpt-6-luna 到第一个 Nexent 智能体：配置、调试与发布

这次我选择已接入的 gpt-6-luna，创建"Nexent 部署准备助手"。实际操作覆盖了基本信息、角色指令、开场白、权限、高级设置、调试和发布。调试结果可以证明这条测试输入得到了符合预期的答复；发布页面也显示 Agent 已上线。现有记录没有包含发布后从普通工作台入口再次发起对话的画面，因此不把那一步写成已验证。

一、先把 Agent 的任务范围定窄

我没有一开始就给 Agent 加知识库、MCP、Skill 或协作智能体。这些配置会带入其他变量；这次先看模型选择和任务说明能否把一件具体任务说清楚：用户只说"Docker 已安装"时，Agent 要继续确认 CPU、内存、磁盘和 Docker 服务状态，不能替用户补齐机器信息。

Nexent 的智能体配置引导把操作分成创建、对话配置、个性化编辑、调试发布和使用几个阶段，很详细。

配置面板上方的逐步引导会在不同区域给出操作提示。我沿着提示先找到创建入口，再继续填写模型、角色指令和发布属性；这些步骤提示适合第一次熟悉页面，后续修改 Agent 时仍要回到具体字段检查保存状态。

新建时我把名称设为"Nexent 部署准备助手"。它和已有智能体相互独立，后面调试角色指令或调整权限时，不会覆盖其他正在使用的 Agent。这里的名称会显示给使用者，变量名则供系统识别，两个字段承担的作用不同。这个弹窗只要求输入展示名称，变量名、模型和权限要等进入配置页后再设置。创建对话框没有可用模板，所以我从空白配置开始，也没有导入其他人的 Agent 配置；到这里还只是建立空白配置，模型和任务约束都没有保存。

二、填写基本信息、模型和角色指令

创建完成后，我先补齐展示名称、变量名和简介，再在模型配置区域选择 gpt-6-luna。这次使用的字段如下：

配置项	实际设置	用途
展示名称	Nexent 部署准备助手	工作台和 Agent 页面展示给使用者
变量名	nexent_deploy_readiness	用于标识和调用该 Agent
简介	根据用户提供的主机和 Docker 信息整理 Nexent 部署前检查项	简要说明任务范围
大语言模型	gpt-6-luna	作为该 Agent 的运行模型
知识库、工具、Skill、协作 Agent	未添加	让本次调试只围绕模型和职责约束进行

变量名采用小写英文和下划线，方便在 API 示例里识别；简介只说明它处理什么信息，没有把整段任务说明塞进简介。Agent 自己的模型选择需要单独设置 ，不能只因为平台已经接入 gpt-6-luna，就认为新 Agent 会自动使用它。

我把角色指令写成一组可检查的约束：回答按"已知环境""待确认项""下一步检查"组织；没有用户输入的 CPU、内存、磁盘和 Docker 状态要留作待确认；需要补查时给出命令，但不能声称自己运行过命令。实际配置的核心规则如下：

回答时按"已知环境""待确认项""下一步检查"组织。需要补查的信息要给出对应命令，但不要声称自己已经运行过这些命令。

1. 缺失信息写"待确认"，不要用常见配置替用户补值。
2. 区分"低于文档基线""达到文档基线"和"资料不足"，不要把三种状态混为一谈。
3. 提供检查命令时说明命令应在目标服务器上运行，并解释它要检查的字段。
4. 不要求用户粘贴密码、API Key、访问令牌或 SSH 私钥；用户误发密钥时，不要复述密钥。
5. 不声称已经连接服务器、运行命令或检查服务状态。

指令中的资源数字用来判断用户提供的配置是否达到 Nexent v2.8.0 的部署基线：CPU 至少 4 核、内存至少 8 GiB、可用磁盘至少 40 GiB。未提供数值时，Agent 应标成"资料不足"；有数值但低于基线时，再标明具体差距。这样回答不会把"尚未测量"和"已经低于要求"混成同一种状态。

开场白和示例问题也保持在同一任务里。开场白请用户提供系统、CPU、内存、磁盘和 Docker 版本；示例问题则用 CentOS Stream 9 部署 Nexent 的检查需求。知识库、技能、工具和协作智能体区域都留空，避免开场问题把用户带到本次没有验证的能力上。

第一次配置时，我把可选项留在默认状态，没有同时调运行步数、输出 Token 预留和其他运行策略。页面里已设置开场白与示例问题，其他资源为空；因此后面出现的回答主要反映模型选择和职责约束，而不是某个知识库或工具返回的内容。

三、用一条信息不完整的输入调试

我先用一条刻意缺少机器数据的问题检查 Agent 是否会"脑补"。输入只说明目标系统和部署版本，并提到 Docker 已安装，没有给出 CPU、内存、磁盘、Docker 服务状态或 Compose 信息：

我准备在 CentOS Stream 9 上部署 Nexent v2.8.0，目前只知道 Docker 已安装。
请先告诉我还缺哪些信息，并给出对应的检查命令，不要假定我的机器配置。

调试面板开始运行后，我重点看三个地方：已知环境有没有严格沿用输入；缺失字段有没有标成"待确认"；命令是否明确要在目标服务器上执行。动图录下了这次回复从生成到完成的过程，便于对照它如何把条件和检查步骤组织出来。回复出现后我没有马上把它当作通过，而是把输入原文、状态标签和回答结构一起核对。更重要的是检查它有没有把未经提供的数据当成已知值，最终完成状态本身不足以判断规则是否生效。

动图结束后，回答已经进入完成状态；我再回看输入与输出，确认列表里的待确认字段都能在原始问题中找到依据。检查命令也应只作为建议展示，不能被描述成已经在那台 CentOS 主机上运行过。对这次结果，我保留了运行过程，也单独留下一张完成态画面，便于读者停下来逐项核对。

完成后的回答把 CentOS Stream 9 和目标 Nexent v2.8.0 列为已知信息，同时把"Docker 已安装"与"Docker 服务可用、版本符合要求"分开处理。CPU 核数、内存总量、可用磁盘、Docker 服务状态、Compose 插件和网络/端口仍列在待确认项中；它没有把这些项目编造成某个具体数值。

回答还给了可以在目标服务器上执行的命令。它们是 Agent 建议用户检查的命令，不是这次在调试面板里实际运行过的结果：

nproc

free -h

df -hT

docker --version

systemctl status docker --no-pager

docker compose version

调试结果还把资源状态拆成三类：低于基线、达到基线和资料不足。这个区分很实用------例如没有 nproc 输出时，不能说 CPU 不达标；同样，"Docker 已安装"也不能直接推出 Docker daemon 正在运行。下一轮测试如果提供了真实环境数字，就应该再检查 Agent 能否准确分类；现有素材只记录了信息缺失这一条用例，因此不把第二条用例描述成已经通过。

四、配置权限并发布

调试之前，我在发布属性里把权限设为"选定用户组可读"，当前画面显示的组是 Default Group，并勾选"设置为主智能体"。高级设置保留了页面初始值：最大运行步数为 15、运行输出预留为 4096 tokens；运行摘要、对话 Metadata、自我验证、严格输出协议与静默修复、A2A 等开关没有开启。

正式发布前要再次确认用户组范围。官方"开始问答"说明中，智能体需要同时满足已发布、设置为主智能体、当前用户有使用权限，才会出现在可选列表里。权限设得过窄时，即使发布状态正常，其他用户也可能看不到它；这次截图记录的是当前测试组的配置，不代表所有租户都使用同一个组名。

进入"智能体发布"页签后，我打开发布窗口，填写版本名称和发布说明，再点击发布。确认窗口记录了这次的首次发布信息；弹窗本身只是发布前的最后一步，是否成功还要等状态页返回结果。权限与运行选项是在配置阶段设好，发布阶段则生成一个可识别的版本记录。我把发布说明写成"第一次发布"，方便后续区分初始版本和调整后的版本；如果发布尚未返回状态，不能直接从弹窗推断已经上线。

版本说明写入后，发布弹窗仍需要显式确认。点击按钮之后我等待页面状态更新，再从版本详情核对上线标记；这样能把"填写了发布信息"和"版本实际发布成功"分开记录，也避免只依据弹窗内容下结论。

发布完成后，页面状态变为"已上线"，版本列表显示已有一个版本。它还提供体验链接、分享入口和 API 调用示例；这些内容说明页面已进入发布状态，但我没有在这次记录中用 API Key 发起 API 请求。

页面里的体验链接是回环地址，访问者的浏览器会把它指向访问者自己的设备；它适合本机调试，不能直接当成外部用户可以访问的公网链接。我这次确认到的是 Agent 发布成功；普通工作台入口中的可见性和最终对话还需要单独验证。

详情页给出的 API 示例使用 Bearer Token。下面保留字段结构，令牌只用占位符，不要把真实 API Key 写进 Agent 的指令、文章、截图或公开代码：

curl -N -X POST '部署地址/nb/v1/chat/run' \
  -H 'Authorization: Bearer <YOUR_API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"agent_name":"nexent_deploy_readiness","query":"Hello"}'

这条命令来自发布页展示的调用示例，不代表我已经执行过 API 调用。若要给其他机器或用户使用，先配置可访问的域名和反向代理，再核对访问权限；API Key 也应按服务端凭据管理，不要把示例占位符替换成真实值后公开分享。

五、把调试和发布结果分开记录

这次操作确认了 gpt-6-luna 已绑定到"Nexent 部署准备助手"，职责约束能要求模型保留缺失字段，并给出目标服务器上的检查命令；发布页随后显示 Agent 已上线。范围仍然是一条信息不完整的调试输入和一次发布状态确认，没有测试完整环境输入、其他用户组可见性，也没有验证从普通工作台发起的发布后对话或实际 API 请求。

检查环节	本次记录	可以确认的内容
基本配置	名称、变量名、简介与 gpt-6-luna 已设置	Agent 有独立身份并绑定模型
约束调试	缺失信息用例完成	答复区分已知项、待确认项，并给出检查命令
权限配置	选定用户组可读，主智能体已勾选	当前发布配置包含主智能体和一组读取权限
发布状态	详情页显示"已上线"，共 1 个版本	发布动作完成
工作台/API 验证	没有对应的实际对话或请求记录	不据此声称普通用户已经完成调用

创建第一个 Agent 时，把任务限制在"根据用户提供的环境信息整理待检查项"，更容易判断职责约束是否起作用。下一次从普通工作台入口验证时，仍需用当前账号选择这个 Agent，确认权限、模型和回答都与调试页一致；如果之后加入知识库或工具，也应把它们作为新的变量单独测试。

• Nexent 智能体配置说明
• Nexent 开始问答说明