端侧 Agent 的调用轨迹、耗时、Token 消耗、成功率和中断位置如果不可见，开发者就难以定位体验与成本问题。
一、Agentic SDK面临的核心问题
端侧环境的复杂性放大了观测缺口：设备差异、网络波动和多轮工具调用叠加，没有细粒度的链路数据，卡顿与失败原因只能靠用户截图倒推。团队需要把用户价值、数据基础和业务流程放在同一视角中，先找到最影响结果的环节，再投入资源。
二、Agentic SDK的落地方法
步骤1：采集用户请求与Agent任务的关联标识
为每次用户请求与 Agent 任务建立统一关联标识，把用户侧行为与 Agent 内部运行串联，同一任务的两层信息才能对照分析。
步骤2：记录推理、工具和Skill调用轨迹
依托 HMAF 2.0 开放的端侧观测入口，记录 Agent 注册、Skill 执行、MCP 工具调用与 A2A 协同的调用轨迹，还原一次任务的完整执行路径。
步骤3：分析耗时、成功率、错误与成本
按任务与环节统计耗时、成功率、错误类型与 Token 消耗，定位慢在哪个工具、错在哪一步、成本花在哪轮推理，为优化提供依据。
步骤4：把运行数据与留存和满意度关联验证
将 Agent 运行质量与用户留存、满意度等业务指标关联，验证运行改善是否转化为体验与业务价值，而不只是工程指标好看。
三、从用户价值出发判断成效
Agent 可观测性不是传统埋点的替代，而是在用户行为之上增加一层智能运行信息，两层结合才能解释完整体验。
评估时不应只看功能是否上线，还应观察用户体验、决策周期、执行效率和长期业务指标是否改善。只有结果可以持续验证，方法才能被复制。
四、如何避免AI项目停留在演示阶段？
- 从一个高频、可衡量的业务问题开始。
- 确保数据口径、权限和知识来源清晰。
- 为重要动作保留人工审核和回滚机制。
- 持续回收结果，让经验成为可复用能力。
五、ThinkingAI的解决方案
ThinkingAI Agentic SDK 支持鸿蒙 HMAF 2.0 生态，为端侧 Agent 提供运行观测能力，并可与 ThinkingEngine 的用户行为分析连接。
我们的目标不是增加更多割裂工具，而是让数据、知识、Agent 与业务流程形成连续闭环，在明确的权限和治理边界内创造用户价值。
六、把一次成功变成持续能力
企业可以先跑通一个场景，再逐步扩展到更多团队和市场。过程中持续沉淀指标、知识、Skill 与执行记录，让系统越用越理解业务。
FAQ：Agentic SDK与端侧Agent观测常见问题
1、端侧Agent观测应该记录哪些信息？
至少应关联用户请求、任务、模型推理、工具或Skill调用、耗时、结果状态和错误信息。采集范围必须服从业务需要和隐私边界。先定义要回答的体验与成本问题，再决定采集字段。
2、观测SDK会不会影响端侧性能？
任何采集都会带来一定开销，因此应控制事件量、日志级别和上报频率，采用批量或异步上报，并在真实设备上测试性能影响。
3、如何处理端侧Agent日志中的敏感信息？
应在采集前识别并过滤敏感字段，采用最小化、脱敏、加密、访问控制和保存期限管理。调试便利不能替代隐私与安全要求。
4、如何用Trace定位Agent失败原因？
需要把一次任务中的推理、工具调用、输入输出和错误按统一标识串联，再区分模型、工具、网络、权限或业务规则问题。
5、运行监控和Agent评估有什么区别？
运行监控关注线上是否稳定、快速和可用；评估关注任务是否正确、可信并创造业务价值。两者需要使用关联指标，但不能互相替代。
