北京
```html Copilot Studio智能体运行日志两种写法对比与导出要点 Copilot Studio智能体运行日志两种写法对比与导出要点
一个Copilot Studio智能体跑完一轮对话，返回了答案。然后呢？它调用过哪些技能、哪些工具、哪些连接器、哪些MCP服务器、哪些知识源、哪些工作流、哪些文件处理步骤——这些信息，一份简单的聊天记录根本装不下。
出问题的时候，开发者要回答的是一串很具体的问题：哪个能力被调用了？哪一步失败或者被跳过了？工具成功了但整体任务是不是还没完成？要求的输出文件到底生成了没有？这次运行能不能和Copilot Studio Observe的追踪记录或其他平台遥测对上号？
针对这些，一种轻量的Conversation Run Log（对话运行日志）被提了出来：按每次对话或每次运行生成一份，给开发者一份清晰、可分享的执行记录。它不替代平台遥测，但能让排障、交接和质量复查变得可重复得多。
这里对比两种日志写法：一种是详细的执行轨迹，一种是围绕能力的精简审计摘要。
方法一：提示词驱动的计划与按需运行日志
这是开发和测试阶段最快的一条路。对话一开始，就让智能体先建计划，边做边记。比如直接对它说：为这次对话创建一个Plan markdown文件，记录所有步骤，方便我测试和导出。
智能体会生成一份计划，描述预期的工作流——接收文件、调用技能、检查输出、生成报告、返回产物。测试结束时再提示它：Conversation Run Log，或者更完整一点：为这次对话创建一个Conversation Run Log markdown文件。智能体便基于对话上下文和本次会话中能拿到的执行细节，生成一份Markdown摘要。
好处是不需要写永久的智能体指令，适合临时测试和演示，还能验证智能体有没有按自己的计划走——计划本身就是一把尺子，用来对照哪些步骤完成了、哪些跳过了、哪些失败了。
局限也很明确：这个方法依赖会话。智能体只能从当前对话里还够得着的上下文和遥测中重建运行过程。如果生成的文件是临时的、已经不在运行时存储位置上了，那在离开会话之前可能得重新生成一遍。实操建议是：趁会话还活着，把Plan和Conversation Run Log都下载下来，别指望运行时会话结束或重置之后文件还在。
方法二：指令驱动的审计日志
第二种做法把运行日志的要求直接写进智能体指令，不再依赖开发者每次记得敲那句开场提示，而是引导智能体在跑相关任务时稳定地留下审计记录。
指令片段要求尽可能捕获这些内容：
- 对话ID、会话ID、运行/追踪/关联ID
- 智能体名称、环境、UTC起止时间戳
- 用户请求及相关的后续指令
- 被调用的能力：工具、MCP服务器、技能、知识源、动作、连接器、工作流和文件
- 每个实质步骤的简要记录，含状态和输出摘要
- 生成的产物及其文件名
- 警告、错误、限制和恢复指引
- 最终状态：Completed、Completed with warnings、Partial或Failed
指令里还有几条硬规矩：不许编造ID、时间戳、遥测、能力活动或执行结果，平台没暴露的信息一律写“Not available in current session”；日志里绝不能出现密钥、凭据、令牌、连接字符串或敏感用户数据；处理没完成或失败时，要返回日志，显示已完成的步骤、失败点和继续所需的东西；只有所需的能力执行和要求的交付物真的完成了，才能确认成功。
这套写法的价值在于跨对话的一致性，对拥有多个技能、MCP工具、连接器、工作流和知识源的智能体尤其管用。它也鼓励如实报告部分执行的情况，方便支持团队在ID可用时，把智能体的运行日志和Copilot Studio Observe的追踪记录对着看。还有一点很关键：它明确阻止智能体去编造拿不到的遥测。
局限同样存在。指令能引导智能体产出日志，但保证不了平台把每一处内部执行细节都暴露出来——对话ID、运行ID、工具遥测、精确时间戳，运行时未必对智能体可见。文件持久化的问题也不会因为写了指令就自动解决：Markdown文件如果生成在临时运行时存储里，就得趁它还在的时候下载或导出。
一句话收束：用计划测意图，用运行日志证执行，两者都要在运行时会话结束前导出。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
