ਜੇਕਰ ਤੁਸੀਂ ਸਾਲਾਂ ਤੋਂ PHP ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਅੰਦਰ business logic ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਵਿੱਚ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ, ਤਾਂ Model Context Protocol ਦੇ ਟਿਊਟੋਰਿਅਲ ਦੇਖਣਾ ਇੱਕ ਬੰਦ ਦਰਵਾਜ਼ੇ ਦੇ ਬਾਹਰ ਖੜ੍ਹੇ ਹੋਣ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਲਗਭਗ ਹਰ ਗਾਈਡ TypeScript ਜਾਂ Python ਨੂੰ ਮੰਨ ਕੇ ਚੱਲਦੀ ਹੈ। ਉਹ ਅਧਿਕਾਰਤ SDKs, npm installs, ਅਤੇ pip packages ਬਾਰੇ ਦੱਸਦੇ ਹਨ। ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਰਾ ਵਪਾਰਕ ਡੇਟਾ—ਗਾਹਕਾਂ ਦੇ ਰਿਕਾਰਡ, ਆਰਡਰ ਇਤਿਹਾਸ, ਇਨਵੈਂਟਰੀ ਸਿਸਟਮ—PHP codebases ਵਿੱਚ ਰਹਿ ਜਾਂਦਾ ਹੈ ਜੋ AI ਟੂਲਿੰਗ ਦੀ ਮੌਜੂਦਾ ਲਹਿਰ ਲਈ ਅਦਿੱਖ ਜਾਪਦਾ ਹੈ।

ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ MCP ਲਈ ਉਹਨਾਂ SDKs ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। MCP ਕੋਈ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ wire protocol ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ runtime standard input ਤੋਂ ਟੈਕਸਟ ਦੀ ਇੱਕ ਲਾਈਨ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, JSON parse ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ JSON ਲਿਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। PHP LLMs ਦੇ ਆਉਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਬਿਲਕੁਲ ਇਹੀ ਕਰ ਰਿਹਾ ਹੈ।

MCP ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

MCP ਦਾ ਮਤਲਬ Model Context Protocol ਹੈ। ਇਸਦੇ ਮੂਲ ਵਿੱਚ, ਇਹ AI assistants ਨੂੰ ਡੇਟਾ, ਟੂਲਜ਼ ਅਤੇ ਬਾਹਰੀ APIs ਨਾਲ ਜੋੜਨ ਲਈ ਇੱਕ open standard ਹੈ। ਹਰ assistant ਜਾਂ model ਲਈ ਇੱਕ custom integration ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ compliant interface ਬਣਾਉਂਦੇ ਹੋ। ਕੋਈ ਵੀ client ਜੋ MCP ਨੂੰ ਸਮਝਦਾ ਹੈ, ਉਹ PHP, Laravel, ਜਾਂ ਤੁਹਾਡੇ ਖਾਸ database schema ਬਾਰੇ ਕੁਝ ਵੀ ਜਾਣੇ ਬਿਨਾਂ ਤੁਹਾਡੇ server ਨਾਲ ਗੱਲ ਕਰ ਸਕਦਾ ਹੈ।

ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, MCP JSON-RPC 2.0 ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ request ਇੱਕ ਸਧਾਰਨ JSON object ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ method name, parameters, ਅਤੇ ਇੱਕ ID ਹੁੰਦੀ ਹੈ। Server ਇੱਕ ਹੋਰ JSON object ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਜਾਂ ਤਾਂ ਕੋਈ result ਹੁੰਦਾ ਹੈ ਜਾਂ ਕੋਈ error।

ਇੱਕ server ਤਿੰਨ primitives ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

  • Tools: ਉਹ ਕਾਰਵਾਈਆਂ ਜੋ model ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ tool ਡੇਟਾਬੇਸ ਨੂੰ query ਕਰ ਸਕਦਾ ਹੈ, ਸਟੇਟਸ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ third-party API ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
  • Resources: ਸਟੈਟਿਕ ਜਾਂ semi-static ਡੇਟਾ ਜਿਸਦਾ ਮਾਡਲ ਇੱਕ URI ਰਾਹੀਂ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ। ਫਾਈਲਾਂ, configuration ਦਸਤਾਵੇਜ਼ਾਂ, ਜਾਂ reference datasets ਬਾਰੇ ਸੋਚੋ।
  • Prompts: ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕੀਤੇ ਗਏ templates ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਸਿਸਟਮ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਯਾਦ ਰੱਖਣ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕੰਟਰੋਲ ਅੰਤਰ ਹੈ। Tools ਮਾਡਲ ਦੁਆਰਾ ਕੰਟਰੋਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। Assistant ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਦੋਂ ਇੱਕ ਨੂੰ ਕਾਲ ਕਰਨਾ ਹੈ। Resources ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਕੰਟਰੋਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। Server ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਡੇਟਾ ਉਪਲਬਧ ਹੈ ਅਤੇ ਮਾਡਲ ਸਿਰਫ਼ ਉਹ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਨੂੰ ਸਹੀ ਰੱਖਣ ਨਾਲ ਤੁਹਾਡਾ architecture ਅਨੁਮਾਨਯੋਗ (predictable) ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੋਗੇ ਕਿ ਮਾਡਲ ਅਜਿਹੇ resources ਦੀ ਭਾਲ ਕਰੇ ਜੋ tools ਹੋਣੇ ਚਾਹੀਦੇ ਸਨ, ਜਾਂ ਇਸਦੇ ਉਲਟ।

Transport ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

MCP ਦੋ transport ਮੈਥਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਚੋਣ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ PHP ਪਾਸੇ ਨੂੰ ਕਿਵੇਂ ਲਿਖਦੇ ਹੋ।

stdio ਸਭ ਤੋਂ ਸਧਾਰਨ ਹੈ। MCP client ਤੁਹਾਡੇ PHP script ਨੂੰ ਇੱਕ subprocess ਵਜੋਂ ਲਾਂਚ ਕਰਦਾ ਹੈ। Client ਤੁਹਾਡੇ script ਦੇ standard input 'ਤੇ JSON-RPC ਮੈਸੇਜ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ script standard output 'ਤੇ ਜਵਾਬ ਲਿਖਦਾ ਹੈ। ਇੱਥੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਕੋਈ sockets ਨਹੀਂ ਹਨ, ਖੋਲ੍ਹਣ ਲਈ ਕੋਈ ports ਨਹੀਂ ਹਨ, ਅਤੇ parse ਕਰਨ ਲਈ ਕੋਈ authentication headers ਨਹੀਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਡਾ tool ਅਤੇ ਤੁਹਾਡਾ client ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਹਨ, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤ ਕਰਨ ਲਈ ਸਹੀ ਜਗ੍ਹਾ ਹੈ।

stdio ਰਾਹੀਂ ਚੱਲਣ ਨਾਲ ਤੁਹਾਡੇ PHP process 'ਤੇ ਦੋ ਸਖ਼ਤ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ, ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਦੇ ਵੀ stdout 'ਤੇ non-protocol ਡੇਟਾ ਨਹੀਂ ਲਿਖਣਾ ਚਾਹੀਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ debug statement echo ਕਰਦੇ ਹੋ ਜਾਂ PHP notice ਨੂੰ ਲੀਕ ਹੋਣ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ client ਦੇ parser ਨੂੰ ਤੋੜ ਦੇਵੋਗੇ। ਸਾਰੀ logging ਅਤੇ diagnostics ਨੂੰ stderr 'ਤੇ ਰੂਟ ਕਰੋ। ਦੂਜਾ, output buffering ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿਓ। PHP stdout ਨੂੰ buffer ਕਰਨਾ ਪਸੰਦ ਕਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ CGI ਜਾਂ web contexts ਵਿੱਚ, ਪਰ CLI scripts ਵੀ ਡੇਟਾ ਰੱਖ ਸਕਦੀਆਂ ਹਨ। ਹਰ response ਨੂੰ ਤੁਰੰਤ flush ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ streams ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ stream_set_write_buffer(STDOUT, 0) ਸੈੱਟ ਕਰੋ ਜਾਂ implicit buffering ਨੂੰ ਬੰਦ ਕਰ ਦਿਓ ਤਾਂ ਜੋ client ਨੂੰ ਉਦੋਂ ਹੀ newline ਮਿਲ ਜਾਵੇ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਭੇਜਦੇ ਹੋ।

Streamable HTTP ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ PHP ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ persistent HTTP endpoint ਵਜੋਂ ਚੱਲਦੀ ਹੈ, ਜਿਸ ਤੱਕ ਆਮ ਤੌਰ 'ਤੇ POST requests ਰਾਹੀਂ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਉਦੋਂ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ server ਕਿਸੇ ਦੂਜੇ host 'ਤੇ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ long-running daemon ਚਾਹੁੰਦੇ ਹੋ ਜਿਸ ਤੱਕ ਕਈ clients ਪਹੁੰਚ ਸਕਦੇ ਹਨ। PHP ਵਿੱਚ, ਇਸਦਾ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ ਕਿ ਰਵਾਇਤੀ request-response cycle ਦੀ ਬਜਾਏ RoadRunner, FrankenPHP, ਜਾਂ ਕਿਸੇ ਸਮਾਨ process manager ਦੇ ਅਧੀਨ ਚੱਲਣਾ, ਜੋ ਹਰ ਕਾਲ ਤੋਂ ਬਾਅਦ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਸਨੂੰ PHP ਵਿੱਚ ਬਣਾਉਣਾ

ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਕਿਸੇ framework ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। PHP ਵਿੱਚ ਇੱਕ minimal MCP server STDIN ਤੋਂ ਪੜ੍ਹਨ, JSON ਨੂੰ decode ਕਰਨ, ਇੱਕ handler ਨੂੰ dispatch ਕਰਨ, ਅਤੇ result ਨੂੰ encode ਕਰਨ ਵਾਲਾ ਇੱਕ loop ਹੈ।

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

ਉਸ loop ਦੇ ਅੰਦਰ, ਅਸਲ ਕੰਮ ਅਜਿਹੇ interfaces ਬਣਾਉਣਾ ਹੈ ਜੋ ਮਾਡਲ ਲਈ ਸਮਝਣਯੋਗ ਹੋਣ।

ਕੋਡ ਤੋਂ ਟੂਲ ਸਕੀਮਾ (schemas) ਤਿਆਰ ਕਰੋ। ਮੁਸੀਬਤ ਖੜ੍ਹੀ ਕਰਨ ਦੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਆਪਣੇ ਟੂਲ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਹੱਥ ਨਾਲ JSON Schemas ਲਿਖਣਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਅਸਲ ਵੈਲੀਡੇਸ਼ਨ ਲੌਜਿਕ (validation logic) ਨਾਲੋਂ ਵੱਖ ਹੋਣ ਦੇਣਾ ਹੈ। PHP ਕੋਲ ਸ਼ਕਤੀਸ਼ਾਲੀ ਰਿਫਲੈਕਸ਼ਨ (reflection) ਸਮਰੱਥਾਵਾਂ ਹਨ। ਆਪਣੇ ਮੈਥਡ ਸਿਗਨੇਚਰਾਂ (method signatures) ਦੀ ਜਾਂਚ ਕਰੋ, ਆਪਣੇ ਫਾਰਮਾਂ ਜਾਂ ਕਮਾਂਡ ਆਬਜੈਕਟਾਂ ਤੋਂ ਮੌਜੂਦਾ ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ ਪੜ੍ਹੋ, ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੋਂ ਸਕੀਮਾ ਤਿਆਰ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਕੋਡ ਨੂੰ ਇੱਕ ਵੈਧ (valid) ਈਮੇਲ ਫਾਰਮੈਟ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ MCP ਸਕੀਮਾ ਨੂੰ ਵੀ ਉਹੀ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ ਬਦਲਦੇ ਹਨ, ਸਕੀਮਾ ਆਪਣੇ ਆਪ ਅਪਡੇਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਕੋਈ ਅੰਤਰ ਨਹੀਂ, ਕੋਈ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋਣਾ ਨਹੀਂ।

ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀਆਂ (errors) ਨੂੰ ਟੂਲ ਗਲਤੀਆਂ ਤੋਂ ਵੱਖ ਕਰੋ। JSON-RPC ਦਾ ਆਪਣਾ ਗਲਤੀ ਸਪੇਸ (error space) ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਟੁੱਟੇ ਹੋਏ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਕਰੋ: ਗਲਤ JSON, ਅਣਜਾਣ ਮੈਥਡ, ਜਾਂ ਗੁੰਮ ਹੋਈਆਂ ਰਿਕੁਐਸਟ IDs। ਜਦੋਂ ਕੋਈ ਟੂਲ ਸਹੀ ਢੰਗ ਨਾਲ ਚੱਲਦਾ ਹੈ ਪਰ ਕਿਸੇ ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੇਲੋਡ (payload) ਦੇ ਅੰਦਰ ਇੱਕ ਐਰਰ ਫਲੈਗ (error flag) ਦੇ ਨਾਲ ਇੱਕ ਆਮ ਨਤੀਜਾ ਵਾਪਸ ਕਰੋ। ਜੇਕਰ ਕੋਈ ਕਸਟਮਰ ਲੁੱਕਅੱਪ ਟੂਲ ਕੋਈ ਮਿਲਦਾ-ਜੁਲਦਾ ਰਿਕਾਰਡ ਨਹੀਂ ਲੱਭਦਾ, ਤਾਂ ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੈ। {"found": false} ਵਰਗਾ ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਨਤੀਜਾ ਵਾਪਸ ਕਰਨ ਨਾਲ ਮਾਡਲ ਸਮਝ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ ਹੈ ਅਤੇ ਅਗਲਾ ਕਦਮ ਚੁਣ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਵਿਆਪਕ ਖੋਜ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇਹ ਉਪਭੋਗਤਾ ਤੋਂ ਸਪਸ਼ਟੀਕਰਨ ਮੰਗ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਦੇ ਬਦਲੇ JSON-RPC ਐਰਰ ਸੁੱਟਦੇ ਹੋ, ਤਾਂ ਮਾਡਲ ਅਕਸਰ ਸੰਦਰਭ (context) ਗੁਆ ਲੈਂਦਾ ਹੈ।

ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਕੰਮ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। PHP ਛੋਟੀਆਂ ਰਿਕੁਐਸਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਇੱਕ ਵੈੱਬ ਰਿਕੁਐਸ ਤੀਹ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਟਾਈਮ ਆਊਟ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ CLI ਸਕ੍ਰਿਪਟਾਂ ਵੀ ਮੈਮੋਰੀ ਜਾਂ ਸਬਰ ਖਤਮ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਕਿਸੇ ਟੂਲ ਨੂੰ ਖਤਮ ਹੋਣ ਲਈ ਮਿੰਟਾਂ ਦੀ ਲੋੜ ਹੈ—ਸ਼ਾਇਦ ਇਹ ਇੱਕ ਵੱਡੀ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜਾਂ ਸਿਸਟਮਾਂ ਵਿੱਚ ਡੇਟਾ ਸਿੰਕ ਕਰਦਾ ਹੈ—ਤਾਂ ਮਾਡਲ ਨੂੰ ਉਡੀਕ ਨਾ ਕਰਵਾਓ। ਤੁਰੰਤ ਇੱਕ ਜੌਬ ਆਈਡੀਐਂਟੀਫਾਇਰ (job identifier) ਵਾਪਸ ਕਰੋ। ਫਿਰ ਉਸ ID ਰਾਹੀਂ ਸਟੇਟਸ ਚੈੱਕ ਕਰਨ ਲਈ ਦੂਜਾ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰੋ। ਤੁਸੀਂ ਪ੍ਰਗਤੀ (progress) ਨੂੰ Redis, ਡੇਟਾਬੇਸ ਟੇਬਲ, ਜਾਂ ਜੇਕਰ ਮਾਤਰਾ ਘੱਟ ਹੈ ਤਾਂ ਇੱਕ ਫਲੈਟ ਫਾਈਲ ਵਿੱਚ ਵੀ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ। ਮਾਡਲ ਨੂੰ ID ਮਿਲਦੀ ਹੈ, ਉਹ ਬਾਅਦ ਵਿੱਚ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਮੁਕੰਮਲ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਜਦੋਂ ਮਾਡਲ ਕੋਲ ਚਾਬੀਆਂ (Keys) ਹੋਣ

ਇੱਕ AI ਮਾਡਲ ਨੂੰ ਟੂਲ ਤੱਕ ਪਹੁੰਚ ਦੇਣਾ ਕਿਸੇ ਮਨੁੱਖੀ ਉਪਭੋਗਤਾ ਨੂੰ ਦੇਣ ਵਾਂਗ ਨਹੀਂ ਹੈ। ਇੱਕ ਮਾਡਲ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੇਰਵਿਆਂ ਦੀ ਗਲਤ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਪ੍ਰਗਟ ਕੀਤੇ ਗਏ ਟੂਲ ਨੂੰ ਪ੍ਰੀਵਿਲੇਜ ਐਸਕੇਲੇਸ਼ਨ (privilege escalation) ਜੋਖਮ ਵਜੋਂ ਮੰਨੋ।

ਸਕੋਪ (scope) ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਸੀਮਤ ਕਰੋ। ਕਦੇ ਵੀ ਇੱਕ ਜਨਰਲ run_sql ਟੂਲ ਪ੍ਰਗਟ ਨਾ ਕਰੋ। find_customer_by_email ਜਾਂ update_order_status ਵਰਗੇ ਵਿਸ਼ੇਸ਼, ਸੀਮਤ ਟੂਲ ਬਣਾਓ। ਮਾਡਲ ਸਿਰਫ਼ ਉਹੀ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਾਮ ਦਿੰਦੇ ਹੋ, ਉਹਨਾਂ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਨਾਲ ਜੋ ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਹਨ।

ਰੀਡ (read) ਅਤੇ ਰਾਈਟ (write) ਪਾਥਾਂ ਨੂੰ ਵੱਖ ਕਰੋ। ਰੀਡ-ਓਨਲੀ ਟੂਲ ਘੱਟ ਜੋਖਮ ਰੱਖਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀਕਰਨ ਵਿਧੀ (confirmation mechanism) ਦੇ ਪਿੱਛੇ ਰੱਖੋ, ਜਾਂ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੂਜੇ ਸਰਵਰ ਤੱਕ ਸੀਮਤ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਰਾਈਟ ਟੂਲ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੇ ਪੜਾਅ ਦੀ ਮੰਗ ਕਰੋ।

ਟੂਲ ਦੇ ਵੇਰਵੇ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਜਿਵੇਂ ਕਿ ਉਹ ਵਾਧੂ ਨਿਰਦੇਸ਼ ਹੋਣ, ਕਿਉਂਕਿ ਉਹ ਹਨ। ਇਸ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ ਕਿ ਮਾਡਲ ਨੂੰ ਕਦੋਂ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਟੂਲ ਕੀਮਤਾਂ ਲੱਭਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਕਹੋ। ਜੇਕਰ ਇਸਦੀ ਵਰਤੋਂ ਸਿਰਫ਼ ਕਸਟਮਰ ID ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੱਸੋ। ਅਸਪਸ਼ਟ ਵੇਰਵੇ ਅਸਪਸ਼ਟ ਵਿਵਹਾਰ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ।

ਆਪਣੇ ਆਉਟਪੁੱਟ ਨੂੰ ਫਿਲਟਰ ਕਰੋ। ਪੂਰੇ Eloquent ਮਾਡਲ ਜਾਂ Doctrine entity ਨੂੰ ਸੀਰੀਅਲਾਈਜ਼ (serialize) ਕਰਕੇ ਨਤੀਜੇ ਵਿੱਚ ਨਾ ਪਾਓ। ਸਿਰਫ਼ ਉਹ ਫੀਲਡਸ ਵਾਪਸ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਮਾਡਲ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜ ਹੈ। ਅੰਦਰੂਨੀ ਫੀਲਡਸ—ਲਾਗਤ ਕੀਮਤਾਂ, ਕਰਮਚਾਰੀ ਨੋਟਸ, ਡੇਟਾਬੇਸ IDs ਜੋ ਅੰਦਰੂਨੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ—ਦਾ ਵਾਇਰ (wire) ਪਾਰ ਕਰਨ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ। ਆਪਣੇ ਰਿਟਰਨ ਸ਼ੇਪ (return shape) ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ।

ਅੰਤ ਵਿੱਚ, ਸਭ ਕੁਝ ਲੌਗ (log) ਕਰੋ। ਟੂਲ ਦਾ ਨਾਮ, ਪਾਸ ਕੀਤੇ ਗਏ ਆਰਗੂਮੈਂਟਸ, ਅਤੇ ਨਤੀਜਾ ਰਿਕਾਰਡ ਕਰੋ। ਜੇਕਰ ਕੋਈ ਮਾਡਲ ਕਿਸੇ ਮਹਿੰਗੀ ਕੁਏਰੀ (query) 'ਤੇ ਲੂਪਿੰਗ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜਾਂ ਅਣਕਿਆਸੇ ਕ੍ਰਮ ਵਿੱਚ ਟੂਲਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਲੌਗ ਹੀ ਇੱਕੋ-ਇੱਕ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਖ ਸਕੋਗੇ।

ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰੀਏ

ਆਪਣੀ PHP ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ AI ਸਹਾਇਕ ਨਾਲ ਜੋ