为什么需要 PTC 模式标准模式的 Agent 工作流大家都不陌生用户提需求模型拆解步骤然后一轮轮调用工具中间靠推理链串联。这种模式处理简单任务很顺手但遇到需要多轮工具协作、中间结果再加工的复杂场景时容易陷入工具调用碎片化的困境——每一步都要重新规划上下文膨胀快且模型对整体流程的把控力弱。PTCProgrammatic Tool Calling程序化工具调用模式的核心思路很直接让模型先写一段代码用代码来编排多轮工具调用。不是每一步都问模型接下来怎么办而是让模型一次性生成一个执行脚本Harness 按脚本调度工具、处理数据流。以生成一份数据分析报告为例这个任务天然适合 PTC要读取原始数据、清洗、统计、可视化、最后汇总成文步骤之间有明确的依赖关系中间结果需要传递。从自然语言到代码需求转化的完整链路假设我们抛给 Harness 这样一个需求分析我桌面 sales_data.csv 的销售趋势按季度汇总画出趋势图写份报告。在 PTC 模式下模型不会立即执行任何文件操作。它会先分析任务结构然后生成类似这样的代码# PTC 生成的编排代码示意 def analyze_sales(): # 1. 读取数据 data tool.read_file(path~/Desktop/sales_data.csv) # 2. 数据清洗与季度聚合 quarterly tool.run_python( import pandas as pd df pd.read_csv(data) df[date] pd.to_datetime(df[date]) return df.groupby(df[date].dt.to_period(Q))[amount].sum().to_dict() , input_datadata) # 3. 生成图表 chart tool.generate_chart( dataquarterly, typeline, titleQuarterly Sales Trend ) # 4. 撰写报告 report tool.llm_generate( promptfBased on quarterly data {quarterly}, write a sales analysis report, context{chart: chart} ) return {report: report, chart: chart, raw_data: quarterly}这段代码的关键在于声明式编排模型定义了做什么和数据怎么流但具体每个工具怎么实现、异常怎么处理由 Harness 的运行时保障。PTC 模式生成的不是最终业务代码而是工具调用图——一种更高层的抽象。多轮工具调用与异常处理上面的理想流程走通了但实际运行中异常不少见。比如 sales_data.csv 编码不对、某列名跟预期不符、或者 generate_chart 服务临时不可用。PTC 模式在这里的优势是异常可捕获、可重试、可降级。Harness 执行这段编排代码时会包装每个工具调用# Harness 运行时层面的伪代码 try: result tool_registry.execute(node, timeout30) except EncodingError as e: # PTC 生成的代码里可声明降级策略 result tool.run_python(fpd.read_csv(..., encodinglatin1)) except ServiceUnavailable: # 自动重试或切换备用实现 result retry_with_backoff(...)更关键的是当异常发生时Harness 的 Trajectory 机制会完整记录代码执行到哪一步、输入输出是什么、异常栈如何。这跟标准模式逐轮对话的日志不同PTC 的轨迹是一个程序执行轨迹你可以像调试普通代码一样设置断点、单步跟进甚至把生成的编排代码拖出来单独跑。实际调试中常见的一个循环是第一次生成的代码漏处理了空值运行报KeyError开发者查看 Trajectory 定位到具体行给模型反馈第 2 步需要加dropna()模型重新生成代码第二次通过。这个生成-执行-调试-修正的闭环PTC 模式比标准模式高效得多因为代码是结构化的错误定位是精确的不像标准模式那样需要在多轮对话记录里翻找。与标准模式的对比同一任务的不同表现为了更直观理解差异还是看回这个数据分析任务。维度标准模式PTC 模式执行粒度每步决策由模型实时推理一次性生成完整执行计划上下文消耗随轮次线性增长易膨胀生成阶段集中消耗执行阶段稳定异常恢复模型重新推理可能偏离原目标代码级 try/catch策略可预设可复现性低同需求可能走不同路径高相同代码输入输出确定人工介入点每轮工具调用后都可干预主要在代码生成和异常断点标准模式下如果第二步数据清洗发现格式问题模型可能会灵机一动换个思路比如跳过清洗直接画图结果报告质量不可控。PTC 模式下代码里写死了流程异常要么按预设策略处理要么明确抛出让用户决策——可控性是核心差异。当然代价也有PTC 对模型的代码生成能力要求更高生成的代码必须语法正确、工具 API 调用准确。Harness 在这里的解法是创造模式——你可以在内存里调试、修改插件甚至让模型基于现有模式生成新的变体。与 LangChain AgentExecutor 的设计哲学差异提到 Agent 编排很难不想到 LangChain 的 AgentExecutor。两者表面都解决模型工具的协作问题但设计哲学有本质不同。AgentExecutor 是模型驱动执行每一步都由模型的推理输出决定工具只是被动等待调用。它的核心循环是thought - action - observation - thought模型始终在场像一位边想边做的工匠。PTC 是代码驱动执行模型退到幕后只在写脚本这个环节出场。脚本一旦生成执行由 Harness 运行时接管模型不再参与中间步骤。这更像一位建筑师画好蓝图交给施工队按图作业。这个差异带来几个实际影响延迟敏感场景PTC 生成代码可能慢几秒但执行阶段无需等待模型推理整体吞吐更高成本敏感场景长任务中 PTC 的模型调用次数显著少于标准 Agent确定性要求金融、医疗等场景PTC 的可审计性更强因为做了什么以代码形式固化LangChain 近年也在推create_structured_chat_agent等偏规划的能力但底层仍是模型逐轮决策。PTC 模式相当于在 Agent 框架里嵌入了一个轻量级 DSL把控制流从模型手里拿回来。适合 PTC 模式的任务特征不是所有任务都值得上 PTC。根据 Harness 社区的实际反馈以下几类场景收益最明显步骤间有明确数据依赖的流水线。比如数据分析报告、CI/CD 流程编排、多源数据 ETL上游输出直接作为下游输入代码天然能表达这种依赖。异常处理策略可预定义。你知道什么错可能发生、该怎么处理比如网络超时重试、文件编码 fallback、API 限流降级。PTC 的代码结构让这些策略有处可放。需要可重复执行。同一份需求要跑多次、或要在不同环境复现代码比对话记录更容易版本管理和 diff。工具调用次数多、但决策逻辑不复杂。如果每步都要模型做复杂推理比如开放式研究、创意写作PTC 的优势发挥不出来反而增加生成代码的复杂度。反过来说探索性强、边界模糊的任务标准模式或创造模式更合适。Harness 提供四种模式切换的意义就在于此——没有银弹但要有趁手的工具。把链路跑通一个实用的启动配置如果你已经通过npx deepseek-ai/dsh web跑起了 Harness体验 PTC 模式只需在创建任务时选择模式。但更高效的做法是在项目里固化配置比如 package.json 里加脚本{ scripts: { dsh: npx deepseek-ai/dsh web --trusted-host localhost, ptc-task: dsh run --mode ptc --file tasks/sales_analysis.yaml } }结合 Harness 的 Python SDK还可以把 PTC 任务嵌入更大的自动化流程比如定时从对象存储拉取数据、触发分析、推送结果。Trajectory 的日志格式是结构化的也方便对接外部可观测平台。目前 v0.1 还是开发者预览版PTC 模式生成代码的稳定性有提升空间特别是遇到冷门工具或复杂数据类型时。但生成代码再执行这条链路本身已经让复杂任务的自动化从模型黑盒往可编程系统迈了一大步。
为什么需要 PTC 模式标准模式的 Agent 工作流大家都不陌生用户提需求模型拆解步骤然后一轮轮调用工具中间靠推理链串联。这种模式处理简单任务很顺手但遇到需要多轮工具协作、中间结果再加工的复杂场景时容易陷入工具调用碎片化的困境——每一步都要重新规划上下文膨胀快且模型对整体流程的把控力弱。PTCProgrammatic Tool Calling程序化工具调用模式的核心思路很直接让模型先写一段代码用代码来编排多轮工具调用。不是每一步都问模型接下来怎么办而是让模型一次性生成一个执行脚本Harness 按脚本调度工具、处理数据流。以生成一份数据分析报告为例这个任务天然适合 PTC要读取原始数据、清洗、统计、可视化、最后汇总成文步骤之间有明确的依赖关系中间结果需要传递。从自然语言到代码需求转化的完整链路假设我们抛给 Harness 这样一个需求分析我桌面 sales_data.csv 的销售趋势按季度汇总画出趋势图写份报告。在 PTC 模式下模型不会立即执行任何文件操作。它会先分析任务结构然后生成类似这样的代码# PTC 生成的编排代码示意 def analyze_sales(): # 1. 读取数据 data tool.read_file(path~/Desktop/sales_data.csv) # 2. 数据清洗与季度聚合 quarterly tool.run_python( import pandas as pd df pd.read_csv(data) df[date] pd.to_datetime(df[date]) return df.groupby(df[date].dt.to_period(Q))[amount].sum().to_dict() , input_datadata) # 3. 生成图表 chart tool.generate_chart( dataquarterly, typeline, titleQuarterly Sales Trend ) # 4. 撰写报告 report tool.llm_generate( promptfBased on quarterly data {quarterly}, write a sales analysis report, context{chart: chart} ) return {report: report, chart: chart, raw_data: quarterly}这段代码的关键在于声明式编排模型定义了做什么和数据怎么流但具体每个工具怎么实现、异常怎么处理由 Harness 的运行时保障。PTC 模式生成的不是最终业务代码而是工具调用图——一种更高层的抽象。多轮工具调用与异常处理上面的理想流程走通了但实际运行中异常不少见。比如 sales_data.csv 编码不对、某列名跟预期不符、或者 generate_chart 服务临时不可用。PTC 模式在这里的优势是异常可捕获、可重试、可降级。Harness 执行这段编排代码时会包装每个工具调用# Harness 运行时层面的伪代码 try: result tool_registry.execute(node, timeout30) except EncodingError as e: # PTC 生成的代码里可声明降级策略 result tool.run_python(fpd.read_csv(..., encodinglatin1)) except ServiceUnavailable: # 自动重试或切换备用实现 result retry_with_backoff(...)更关键的是当异常发生时Harness 的 Trajectory 机制会完整记录代码执行到哪一步、输入输出是什么、异常栈如何。这跟标准模式逐轮对话的日志不同PTC 的轨迹是一个程序执行轨迹你可以像调试普通代码一样设置断点、单步跟进甚至把生成的编排代码拖出来单独跑。实际调试中常见的一个循环是第一次生成的代码漏处理了空值运行报KeyError开发者查看 Trajectory 定位到具体行给模型反馈第 2 步需要加dropna()模型重新生成代码第二次通过。这个生成-执行-调试-修正的闭环PTC 模式比标准模式高效得多因为代码是结构化的错误定位是精确的不像标准模式那样需要在多轮对话记录里翻找。与标准模式的对比同一任务的不同表现为了更直观理解差异还是看回这个数据分析任务。维度标准模式PTC 模式执行粒度每步决策由模型实时推理一次性生成完整执行计划上下文消耗随轮次线性增长易膨胀生成阶段集中消耗执行阶段稳定异常恢复模型重新推理可能偏离原目标代码级 try/catch策略可预设可复现性低同需求可能走不同路径高相同代码输入输出确定人工介入点每轮工具调用后都可干预主要在代码生成和异常断点标准模式下如果第二步数据清洗发现格式问题模型可能会灵机一动换个思路比如跳过清洗直接画图结果报告质量不可控。PTC 模式下代码里写死了流程异常要么按预设策略处理要么明确抛出让用户决策——可控性是核心差异。当然代价也有PTC 对模型的代码生成能力要求更高生成的代码必须语法正确、工具 API 调用准确。Harness 在这里的解法是创造模式——你可以在内存里调试、修改插件甚至让模型基于现有模式生成新的变体。与 LangChain AgentExecutor 的设计哲学差异提到 Agent 编排很难不想到 LangChain 的 AgentExecutor。两者表面都解决模型工具的协作问题但设计哲学有本质不同。AgentExecutor 是模型驱动执行每一步都由模型的推理输出决定工具只是被动等待调用。它的核心循环是thought - action - observation - thought模型始终在场像一位边想边做的工匠。PTC 是代码驱动执行模型退到幕后只在写脚本这个环节出场。脚本一旦生成执行由 Harness 运行时接管模型不再参与中间步骤。这更像一位建筑师画好蓝图交给施工队按图作业。这个差异带来几个实际影响延迟敏感场景PTC 生成代码可能慢几秒但执行阶段无需等待模型推理整体吞吐更高成本敏感场景长任务中 PTC 的模型调用次数显著少于标准 Agent确定性要求金融、医疗等场景PTC 的可审计性更强因为做了什么以代码形式固化LangChain 近年也在推create_structured_chat_agent等偏规划的能力但底层仍是模型逐轮决策。PTC 模式相当于在 Agent 框架里嵌入了一个轻量级 DSL把控制流从模型手里拿回来。适合 PTC 模式的任务特征不是所有任务都值得上 PTC。根据 Harness 社区的实际反馈以下几类场景收益最明显步骤间有明确数据依赖的流水线。比如数据分析报告、CI/CD 流程编排、多源数据 ETL上游输出直接作为下游输入代码天然能表达这种依赖。异常处理策略可预定义。你知道什么错可能发生、该怎么处理比如网络超时重试、文件编码 fallback、API 限流降级。PTC 的代码结构让这些策略有处可放。需要可重复执行。同一份需求要跑多次、或要在不同环境复现代码比对话记录更容易版本管理和 diff。工具调用次数多、但决策逻辑不复杂。如果每步都要模型做复杂推理比如开放式研究、创意写作PTC 的优势发挥不出来反而增加生成代码的复杂度。反过来说探索性强、边界模糊的任务标准模式或创造模式更合适。Harness 提供四种模式切换的意义就在于此——没有银弹但要有趁手的工具。把链路跑通一个实用的启动配置如果你已经通过npx deepseek-ai/dsh web跑起了 Harness体验 PTC 模式只需在创建任务时选择模式。但更高效的做法是在项目里固化配置比如 package.json 里加脚本{ scripts: { dsh: npx deepseek-ai/dsh web --trusted-host localhost, ptc-task: dsh run --mode ptc --file tasks/sales_analysis.yaml } }结合 Harness 的 Python SDK还可以把 PTC 任务嵌入更大的自动化流程比如定时从对象存储拉取数据、触发分析、推送结果。Trajectory 的日志格式是结构化的也方便对接外部可观测平台。目前 v0.1 还是开发者预览版PTC 模式生成代码的稳定性有提升空间特别是遇到冷门工具或复杂数据类型时。但生成代码再执行这条链路本身已经让复杂任务的自动化从模型黑盒往可编程系统迈了一大步。
